Организация бизнес-процессов
Привыкнув к фаст-фуду, китайской одежде и подержанным иномаркам, окружив себя всевозможными HR и PR менеджерами, многие сограждане стали чувствовать себя на уровне капиталистических воротил. В результате кризиса на нашем пространстве громким эхом прокатилось: "Wow!"... В романе Айзека Азимова "Основание" ("Foundation") планета, не обладающая природными ресурсами и какими-либо большими запасами, стала доминирующей только за счет того, что начала поставлять атомную энергию другим. При этом основные знания и технологии сохранялись у них, а инопланетных специалистов готовили как представителей духовенства, объясняя все на уровне религиозных представлений. Конечно, сравнение из серии "лоб-в-лоб", но оно имеет свою подоплеку. Мы уже прошли этот этап, а сегодня многим молодым специалистам придется думать о себе самостоятельно, открывать свой бизнес, находить новые ниши. А для начала… научиться отделять зерна от плевел.
"Хочешь разбогатеть — создай свою религию" — одно из самых верных выражений великих. Для интереса вы можете открыть какую-нибудь книгу из новых религиозных учений. Что там увидите?
. Сложную терминологию, которая объясняется простыми словами и с помощью ранее заученных терминов.
. Опору на примеры из реальной/бытовой жизни, которые понятны каждому.
Занятно, не так ли? А теперь откройте книгу по менеджменту, и… увидите там то же самое! Причем не только по менеджменту, но даже по обычной физике или математике. Мы принимаем терминологию, многое берем на веру, после приобретаем уверенность. Что из этого может выйти? Современному специалисту нужно иметь как можно более широкий круг взглядов на те вопросы, с которыми связана его деятельность. Он должен учитывать различные мнения, что позволит, во-первых, избежать некоторых ошибок, а во-вторых, сфокусировать внимание на наиболее важных вещах (некоторые из которых он может просто не замечать).
Если определенное учение (либо научная дисциплина) имеет широкую практическую применимость и дает пользу людям, то его можно назвать успешным. Но не факт, что оно будет верным либо единственно верным. Не стоит забывать: учение в первую очередь приносит прибыль его создателю и ярым адептам; что, в принципе, нормально. И чем больше распространение, тем большие финансы там крутятся.
В небольшой серии материалов мы рассмотрим некоторые модели, касающиеся рынка программного обеспечения, и сегодня в качестве примера возьмем вариант Microsoft Solutions Framework (MSF). MSF дает свой спектр взглядов на модели, правила и спецификации для создания и распространения ПО, а также эффективного сопровождения бизнес-процессов. MSF — неотъемлемая часть некоторых программ по сертификации специалистов Microsoft. И хотя сегодня эта компания достаточно сильно теряет позиции, нельзя сказать, что накопленные ею интеллектуальные ресурсы бесполезны, очень во многом они правильны.
Какие бывают проекты:)
Проекты принято условно делить на: простые, сложные, мелкие и крупные. Как показывает практика: простой — не обозначает принадлежность к мелкому, а сложный — к крупному. При этом стоит выделить из первого предложения еще одно слово — проекты. По существу, под ними не подразумеваются продукты, как часто путают. Потому как проект может предусматривать не только множество продуктов, но и варианты модификаций, обслуживания и т.п.
Чтобы была более понятна разница, возьмем такой пример, как жилой дом. Это отдельный продукт, но… нужно водо/электроснабжение, обслуживающий персонал, и в целом с учетом всего — это проект. Точно также и с софтом.
Теперь посмотрим, как на создание программного обеспечения смотрит Micorosoft в рамках MSF.
Шесть моделей MSF
Пока только на уровне вводных терминов. Как уже говорилось ранее, MSF представляет из себя набор моделей, каждая из которых обобщает некую ключевую область. Итак:
1. Enterprise Architecture Model. Модель архитектуры предприятия подразумевает набор правил по применению и согласованию информационных технологий с требованиями бизнеса в четырех ключевых направлениях: бизнес, приложения, информация и технология. Это позволяет сократить цикл планирования архитектуры предприятия, то есть сама архитектура формируется на базе интерактивного подхода с плотной взаимосвязью между четырьмя перечисленными пунктами.
2. Risk Management Model. Модель управления рисками подразумевает систематизированный подход к управлению проектами и в первую очередь направлена на опережение. То есть, используя определенные принципы и приемы, можно выявить потенциально возможные проблемы и риски, и принять своевременные решения по их устранению. Эта модель является одной из основополагающих, потому как зачастую возникающие проблемы не только тормозят развитие проекта, но и отодвигают решение более важных задач. Причем модель управления рисками подразумевает непрерывный процесс анализа.
3. Team Model. Модель команды (модель группы) подразумевает все вопросы организации коллектива, правильное распределению ролей/обязанностей, получение максимальной и качественной отдачи от каждого, сюда же входит и распределение постановок задач. Причем, что самое интересное, в рамках Team Model от MSF коллектив рассматривается как группа равноправных (!) сотрудников.
4. Process Model. Модель процесса является отображением гибкой методики управления проектом, его разработкой. Все разбивается на этапы с определением критериев их выполнения. При этом в рамках MSF предлагается смешанный вариант между "водопадной" и "спиральной" моделями разработки (подробнее об этом мы поговорим чуть позже), есть явная привязка к Team Model, то есть на каждом этапе определяется роль каждого отдельного сотрудника.
5. Application Model. Модель приложения позволяет распараллеливание процесса разработки, а после и обслуживания, между несколькими
направлениями (например, пользовательскими, прикладными службами, службами данных).
6. Design Process Model. Модель процесса проектирования подразумевает разбиение работы над проектом на концептуальный, логический и физический этапы. Это соответствует трем сообществам: пользователей, проектировщиков, программистов. Другими словами, требования пользователей трансформируются в реализующие их службы.
Стоит отметить, что базовые концепции, представленные в MSF, конечно же, являются не единственными из возможных, очень многое зависит от специфики проекта, участников команды и так далее. Но люди обычно наступают на одни и те же грабли, и иногда им нужно пояснять даже самые тривиальные вещи, пусть даже возведя все в вид структурированных знаний.
Есть и другая сторона медали, например, когда такие модели берутся незыблемо в качестве основополагающих, идет строгое "следование по бумажке", и в результате столкновения с ситуациями, которые не были описаны, наступает коллапс.
Поэтому, как говорят и сами Microsoft'вцы, MSF следует принимать не как строгую методологию, а как каркас.
Вопросы для обдумывания
Пока мы не приступили к расшифровке некоторых ключевых моделей MSF, возьмем несколько примеров из реальной жизни. Подумайте, как бы в той или иной ситуации поступили бы вы…
Пример №1
Раз уж речь зашла о Microsoft, то укажите примерный процент: насколько повысится эффективность работы пользователей (вас, ваших знакомых, ваших работников) с внедрением Windows Vista и апгрейдом "офиса" до Microsoft Office 2007.
Итеративный подход с появлением все новых и новых версий лежит среди постулатов MSF, но среди аналитиков ПО существует такое понятие по отношению к продуктам, как "пик формы". Можно ли его применить в данном случае к XP и предыдущему "офису"? А также рассмотрите продукты WinAmp, Nero, Mozilla (для последнего проведите сравнение с Apple Safari).
Назовите объективные причины, по которым Vista не стала популярной на данный момент.
Пример №2
Реальная фирма, назовем ее X, занимается разработкой ПО для торговых предприятий. У наиболее популярной версии программы, которая сохранилась еще с прошлых лет, остался MS-DOS'вский интерфейс. Фирма выпустила и Windows-вариант, но продает его дороже, на что потребители не идут. То есть, компромиссов как бы и нет.
Как бы поступили в данной ситуации вы на месте разработчика? Напомню, что автоматизация торгового предприятия связана не только с приобретением ПО, но и более дорогого современного оборудования, специальным обучением персонала и т.п. Причем в итоге все должно окупиться.
Пример №3
Допустим, в рамках web 2.0, то есть обычного онлайн-сервиса, существует некая уникальная система перевода файлов с расширением *.zzz на *.yyy с учетом специфик каждого из стандартов. Она пользуется большой популярностью. Вы задались целью написать программу-конвертор, которая делает то же самое, но в виде отдельного приложения. Онлайн-сервис не предоставляет пользователям такой возможности.
Каким образом вы можете извлечь из этого прибыль? Какие плюсы именно вашего варианта вы бы выделили для пользователей? Какие необходимые атрибуты должны, на ваш взгляд, присутствовать в вашей программе?
Промежуточное завершение
Рынок ПО достаточно специфичен, потому как имеет практически все свойства реального сектора (масштабирование, перепроизводство и т.п.), к которому он сильно привязан, но при этом сохраняет определенную виртуальность, плюс к этому напрямую относится к интеллектуальной форме собственности.
Сегодня мы сталкиваемся с двумя интереснейшими вещами. Некоторые знают, как построить конвейер, но в результате его работы выходят продукты низкого качества. Другие же, наоборот, настроили все отлично, продукция — супер, но производство разрослось, не является мобильным и имеет все время уменьшающийся предел сбыта.
Продолжение следует…
Кристофер christopher@tut.by
"Хочешь разбогатеть — создай свою религию" — одно из самых верных выражений великих. Для интереса вы можете открыть какую-нибудь книгу из новых религиозных учений. Что там увидите?
. Сложную терминологию, которая объясняется простыми словами и с помощью ранее заученных терминов.
. Опору на примеры из реальной/бытовой жизни, которые понятны каждому.
Занятно, не так ли? А теперь откройте книгу по менеджменту, и… увидите там то же самое! Причем не только по менеджменту, но даже по обычной физике или математике. Мы принимаем терминологию, многое берем на веру, после приобретаем уверенность. Что из этого может выйти? Современному специалисту нужно иметь как можно более широкий круг взглядов на те вопросы, с которыми связана его деятельность. Он должен учитывать различные мнения, что позволит, во-первых, избежать некоторых ошибок, а во-вторых, сфокусировать внимание на наиболее важных вещах (некоторые из которых он может просто не замечать).
Если определенное учение (либо научная дисциплина) имеет широкую практическую применимость и дает пользу людям, то его можно назвать успешным. Но не факт, что оно будет верным либо единственно верным. Не стоит забывать: учение в первую очередь приносит прибыль его создателю и ярым адептам; что, в принципе, нормально. И чем больше распространение, тем большие финансы там крутятся.
В небольшой серии материалов мы рассмотрим некоторые модели, касающиеся рынка программного обеспечения, и сегодня в качестве примера возьмем вариант Microsoft Solutions Framework (MSF). MSF дает свой спектр взглядов на модели, правила и спецификации для создания и распространения ПО, а также эффективного сопровождения бизнес-процессов. MSF — неотъемлемая часть некоторых программ по сертификации специалистов Microsoft. И хотя сегодня эта компания достаточно сильно теряет позиции, нельзя сказать, что накопленные ею интеллектуальные ресурсы бесполезны, очень во многом они правильны.
Какие бывают проекты:)
Проекты принято условно делить на: простые, сложные, мелкие и крупные. Как показывает практика: простой — не обозначает принадлежность к мелкому, а сложный — к крупному. При этом стоит выделить из первого предложения еще одно слово — проекты. По существу, под ними не подразумеваются продукты, как часто путают. Потому как проект может предусматривать не только множество продуктов, но и варианты модификаций, обслуживания и т.п.
Чтобы была более понятна разница, возьмем такой пример, как жилой дом. Это отдельный продукт, но… нужно водо/электроснабжение, обслуживающий персонал, и в целом с учетом всего — это проект. Точно также и с софтом.
Теперь посмотрим, как на создание программного обеспечения смотрит Micorosoft в рамках MSF.
Шесть моделей MSF
Пока только на уровне вводных терминов. Как уже говорилось ранее, MSF представляет из себя набор моделей, каждая из которых обобщает некую ключевую область. Итак:
1. Enterprise Architecture Model. Модель архитектуры предприятия подразумевает набор правил по применению и согласованию информационных технологий с требованиями бизнеса в четырех ключевых направлениях: бизнес, приложения, информация и технология. Это позволяет сократить цикл планирования архитектуры предприятия, то есть сама архитектура формируется на базе интерактивного подхода с плотной взаимосвязью между четырьмя перечисленными пунктами.
2. Risk Management Model. Модель управления рисками подразумевает систематизированный подход к управлению проектами и в первую очередь направлена на опережение. То есть, используя определенные принципы и приемы, можно выявить потенциально возможные проблемы и риски, и принять своевременные решения по их устранению. Эта модель является одной из основополагающих, потому как зачастую возникающие проблемы не только тормозят развитие проекта, но и отодвигают решение более важных задач. Причем модель управления рисками подразумевает непрерывный процесс анализа.
3. Team Model. Модель команды (модель группы) подразумевает все вопросы организации коллектива, правильное распределению ролей/обязанностей, получение максимальной и качественной отдачи от каждого, сюда же входит и распределение постановок задач. Причем, что самое интересное, в рамках Team Model от MSF коллектив рассматривается как группа равноправных (!) сотрудников.
4. Process Model. Модель процесса является отображением гибкой методики управления проектом, его разработкой. Все разбивается на этапы с определением критериев их выполнения. При этом в рамках MSF предлагается смешанный вариант между "водопадной" и "спиральной" моделями разработки (подробнее об этом мы поговорим чуть позже), есть явная привязка к Team Model, то есть на каждом этапе определяется роль каждого отдельного сотрудника.
5. Application Model. Модель приложения позволяет распараллеливание процесса разработки, а после и обслуживания, между несколькими
направлениями (например, пользовательскими, прикладными службами, службами данных).
6. Design Process Model. Модель процесса проектирования подразумевает разбиение работы над проектом на концептуальный, логический и физический этапы. Это соответствует трем сообществам: пользователей, проектировщиков, программистов. Другими словами, требования пользователей трансформируются в реализующие их службы.
Стоит отметить, что базовые концепции, представленные в MSF, конечно же, являются не единственными из возможных, очень многое зависит от специфики проекта, участников команды и так далее. Но люди обычно наступают на одни и те же грабли, и иногда им нужно пояснять даже самые тривиальные вещи, пусть даже возведя все в вид структурированных знаний.
Есть и другая сторона медали, например, когда такие модели берутся незыблемо в качестве основополагающих, идет строгое "следование по бумажке", и в результате столкновения с ситуациями, которые не были описаны, наступает коллапс.
Поэтому, как говорят и сами Microsoft'вцы, MSF следует принимать не как строгую методологию, а как каркас.
Вопросы для обдумывания
Пока мы не приступили к расшифровке некоторых ключевых моделей MSF, возьмем несколько примеров из реальной жизни. Подумайте, как бы в той или иной ситуации поступили бы вы…
Пример №1
Раз уж речь зашла о Microsoft, то укажите примерный процент: насколько повысится эффективность работы пользователей (вас, ваших знакомых, ваших работников) с внедрением Windows Vista и апгрейдом "офиса" до Microsoft Office 2007.
Итеративный подход с появлением все новых и новых версий лежит среди постулатов MSF, но среди аналитиков ПО существует такое понятие по отношению к продуктам, как "пик формы". Можно ли его применить в данном случае к XP и предыдущему "офису"? А также рассмотрите продукты WinAmp, Nero, Mozilla (для последнего проведите сравнение с Apple Safari).
Назовите объективные причины, по которым Vista не стала популярной на данный момент.
Пример №2
Реальная фирма, назовем ее X, занимается разработкой ПО для торговых предприятий. У наиболее популярной версии программы, которая сохранилась еще с прошлых лет, остался MS-DOS'вский интерфейс. Фирма выпустила и Windows-вариант, но продает его дороже, на что потребители не идут. То есть, компромиссов как бы и нет.
Как бы поступили в данной ситуации вы на месте разработчика? Напомню, что автоматизация торгового предприятия связана не только с приобретением ПО, но и более дорогого современного оборудования, специальным обучением персонала и т.п. Причем в итоге все должно окупиться.
Пример №3
Допустим, в рамках web 2.0, то есть обычного онлайн-сервиса, существует некая уникальная система перевода файлов с расширением *.zzz на *.yyy с учетом специфик каждого из стандартов. Она пользуется большой популярностью. Вы задались целью написать программу-конвертор, которая делает то же самое, но в виде отдельного приложения. Онлайн-сервис не предоставляет пользователям такой возможности.
Каким образом вы можете извлечь из этого прибыль? Какие плюсы именно вашего варианта вы бы выделили для пользователей? Какие необходимые атрибуты должны, на ваш взгляд, присутствовать в вашей программе?
Промежуточное завершение
Рынок ПО достаточно специфичен, потому как имеет практически все свойства реального сектора (масштабирование, перепроизводство и т.п.), к которому он сильно привязан, но при этом сохраняет определенную виртуальность, плюс к этому напрямую относится к интеллектуальной форме собственности.
Сегодня мы сталкиваемся с двумя интереснейшими вещами. Некоторые знают, как построить конвейер, но в результате его работы выходят продукты низкого качества. Другие же, наоборот, настроили все отлично, продукция — супер, но производство разрослось, не является мобильным и имеет все время уменьшающийся предел сбыта.
Продолжение следует…
Кристофер christopher@tut.by
Компьютерная газета. Статья была опубликована в номере 15 за 2009 год в рубрике технологии
