Организация бизнес-процессов. Часть 2
Люди голосуют ногами и чаще всего… молча. Начал сильно усложняться С++, никто не стал особенно возмущаться, что тот начинает выходить за грани человеческого понимания, тем более признаваться, что их мозг "не догоняет", и очень многие просто перешли на другие языки и среды разработки. Вообще, мотивация может быть различной, хотя у теоретиков и практиков в такой веселой области, как социальные сети, есть постулат о том, что не стоит отделять технологическую часть от социальной. Это же применимо и для сферы разработки и распространения программных продуктов, сервисов и услуг. Согласно недавно озвученной статистике, 60% пользователей современных навороченных мобильных телефонов просто не могут или не хотят разобраться в большинстве встроенных там технологических решений, и… не пользуются ими. Очень часто люди пытаются проанализировать причины успеха того или иного продукта/сервиса. Например, почему одни СУБД популярны, а другие вроде бы и проще, и удобнее, а находятся на задворках. В принципе, как показывает практика, успех можно рассчитать, но не до конца. Книги, методики и спецификации (например, как это мы видели, обсуждая тезисы MSF) дают не 100% работающие модели, а каркасы.
Вообще есть много интересных аспектов, например, один из них ваш покорный слуга просто называет "феноменом тутбая". Как известно многим, портал раскрутился (приобрел популярность) на сервисе бесплатной электронной почты. При этом, когда он появился, уже было множество других схожих (mail.ru, yahoo и т.п.), байнет считался по существу частью рунета, да и само слово "байнет" тогда было только в кулуарном обиходе, большинство местных интернет-стартапов терпело фиаско, доступ во Всемирную Паутину у нас был и до сих пор является дорогим для обывателя, общая картина напоминала болото. На моей памяти "тутбай" никогда не раскручивался под эгидой "купляйце беларускае", в общем… тут есть много необъяснимых моментов. Хотя очевидно, что был правильно выстроен маркетинг, а его не стоит равнять с функциональностью отдела продаж (как часто путают), поскольку маркетинг практически всегда работает по схеме "один ко многим". Со временем портал стал для очень большого количества людей точкой входа в Интернет, и это уже перевело его на другой уровень, то есть дало новые возможности, которые можно использовать. Это не совсем новая схема функционирования информационных услуг, потому как по такой же работают телевизионные каналы и радиостанции.
Приведем недавний пример с "движением по методике", но при этом почти провальным. MMORPG (для тех, кто незнаком с данной терминологией, эта аббревиатура обозначает ролевую игру в режиме онлайн — одно из самых популярных современных течений) Age Of Conan, созданная по мотивам небезызвестных произведений Роберта Говарда, достаточно хорошо себя разрекламировала, к тому же первый месяц своего существования объявила бесплатным с точки зрения регистрации. Конечно, пользователи повалили туда толпами, миллион набрался очень быстро. Многие даже стали говорить о предстоящей серьезной конкуренции с известнейшей World of Warcraft. Но после того как "бесплатное закончилось", отток оказался чуть ли не фатальным. Виртуальный мир Age Of Conan практически опустел. У продукта оказалось мало зацепок, которые бы сохранили пользовательскую массу в рамках проекта. Это лишний раз доказывает, что все структуры команды должны работать взаимосвязано, как вариант, на равноправном принципе с высокой степенью ответственности.
***
Итак, сегодня в рамках обсуждения организации бизнес-процессов мы продолжим рассмотрение каркасов Microsoft Solutions Framework (MSF). Напомним, что это набор из шести моделей: архитектуры предприятия, управления рисками, команды, процесса, приложения и процесса проектирования. Они предусматривают набор правил и спецификаций при создании и распространении программных продуктов плюс обеспечивают более эффективное использование технологий для решения проблем бизнеса.
В принципе, этот материал, как и предыдущий, мы разделим на две части, то есть в одной рассмотрим некоторые вопросы, в данном случае касающиеся MSF, а потом перейдем к общей части обсуждения. Причем сразу договоримся о том, что MSF — это не единственная методология, которую мы будем рассматривать, потому как вариантов несколько. Причем события последних лет многое видоизменили, ИТ-сектор достаточно турбулентен. Конечно, до марксистских экономических моделей мы не дойдем, хотя можем рассмотреть управляемую динамику Джона Нэша. А сегодня в рамках MSF мы обсудим модель команды (Team Model). В ней, кстати, также есть "запах социализма":).
Team Model
Изначально нужно определиться с важнейшими целями проекта. Среди них выделены следующие.
. Выполнение требований заказчика (пользователей).
. Соответствие проектным ограничениям.
. Соответствие спецификациям, которые основаны на требованиях заказчика.
. Выявление и устранение недоработок.
. Повышение эффективности труда пользователей.
. Корректная установка и сопровождение.
Вот такие шесть пунктов, достаточно абстрактных на первый взгляд. Но на самом деле они подразумевают правильный подход к делу. Например, первым пунктом идет не выполнение проекта в срок или укладывание в бюджет, а выполнение требований заказчика. Если заказчик (или же группа пользователей) недоволен, то проект нельзя назвать успешным.
Второй пункт касается проектных ограничений, в число которых входит соблюдение сроков и установленного бюджета. Здесь все понятно.
Третий пункт касается конкретики в договоренностях между разработчиками и заказчиком, что подразумевает составление подробной функциональной спецификации, детально описывающей продукт. С одной стороны это защищает разработчиков, потому как они выполняют все "по бумажке", а с другой, по этой же "бумажке" заказчик может требовать. То есть, самое главное в этом — конкретика во взаимоотношениях.
Пункт насчет выявления и устранения ошибок/недоработок стандартен. Конечно, желательно все учитывать и исправлять заранее. Для этого необходимы тестеры.
Повышение эффективности труда пользователей… В прошлом материале мы спросили вас о том, насколько эффективным для вас, ваших знакомых или сотрудников является переход на Windows Vista и новый Office. Так вот, расшифровывая данный пункт, представители Microsoft изначально говорят о том, что продукт может быть признан в пользовательском сообществе только в том случае, если позволяет работать эффективнее, иначе — провал. Честно сказать, я не совсем понял прикол с "резиновой лентой" в новом Office, которая оказалась не такой уж и удобной, также возникли проблемы с форматом *.docx, который не имеет широкого хождения, а плюсы его использования не так очевидны. В общем, с моей точки зрения, это и есть тот провал (по сравнению с Office 2003), о котором написано. Хотя могу и ошибаться, причем в данном случае имеется в виду несколько другой момент — пользователей нужно и убедить в эффективности применения продукта.
Корректная установка и сопровождение. В данном случае речь идет о том, чтобы программа инсталляции вела себя корректно и без ошибок, потому как это первое впечатление. Плюс к этому немаловажную роль играют сопровождение и техническая поддержка продукта.
Но фишка не в этом, а в том, что данные шесть пунктов подразумевают шесть ролей в коллективе соответственно указанным выше пунктам. . Product management. Управление продуктом.
. Program management. Руководство программой.
. Development. Разработка.
. Testing. Тестирование.
. User education. Обучение пользователей.
. Logistic management. Управление материально-техническим снабжением.
Теперь о социализме. Дело в том, что все шесть ролей, соответствующих целям, равноправно влияют на успешность продукта, то есть единоначалие здесь отсутствует. Работа каждого сотрудника зависит от работы другого. Естественно, это повышает уровень ответственности каждого. Причем в современных реалиях достаточно бурно обсуждается эффективность существующих моделей поощрений (что, кстати, не указано в описании MSF Team Model). Например, вариант неравноправия часто может сработать в минус для эффективности работы коллектива. Продукт — это результат работы команды.
Сама модель, представленная в рамках MSF, является достаточно гибкой и подразумевает повышение эффективности. Team Model существует с плотной привязкой к Process Model, о которой мы поговорим в следующем материале, поскольку тема достаточно обширна.
Вопросы для обдумывания
Мы продолжим тенденцию обсуждения реальных примеров из жизни. Итак…
Пример №1. 1999-й и Delphi
Одна местная компания в 1998-1999 гг. взялась за разработку достаточно крупного проекта, связанного с переводом сложной программной оболочки из ДОСовского интерфейса в Windows. Вся соль ситуации заключалась в том, что все делалось в Borland/Inprise Delphi 4 с использованием новых технологий данной среды разработки. Произошла интересная катавасия, поскольку программная оболочка предварительной версии просто не загружалась на ноутбуке у заказчика. Ситуация оказалась в итоге экстремальной, поскольку это была ошибка… внутри Delphi с поддержкой Intel'вских процессоров (наверняка многие помнят этот момент, поскольку об этой ошибке было заявлено официально и много писали). Вот это действительно форс-мажор. Вариантов развития ситуации было несколько, а именно: переписать все в другой IDE, например, в C++ Builder, или же ждать исправлений со стороны Borland, доведя разработку до конца, а в документации временно указать на наличие существующей ошибки. Пошли по второму пути. Причем заказчик не разбирался в тонкостях и в дальнейшем к услугам данной фирмы уже не обращался. И вообще, об этом моменте оба хотели бы забыть. А как в этой ситуации на месте разработчиков поступили бы вы?
Пример №2
Gothic3… Пожалуй, самый глобальный и сильный игровой проект, даже если смотреть с позиций нынешнего, 2009 года. Огромный виртуальный мир, нелинейный сюжет, множество городов и NPC, одних диалогов около 700 страниц. Специфика игрового рынка состоит в том, что в качестве заказчиков выступают издатели, а главное их требование — соответствие срокам, хотя к таким играм, как Gothic, существует и особое отношение. Очевидно, что Gothic3 рассматривалась как прорыв, игра могла вполне рассчитывать на мировое первенство. Разработчики — Piranha Bytes (Pluto13 Gmbh), которые сделали и две предыдущие версии, издатель — Jowood. Продукт вышел сырым, содержал некоторые обидные ошибки, соответственно, не нашел того отклика среди пользователей, который ожидался. Понятно, что проект очень глобальный и не уложиться в сроки с ним проще простого. После третьей версии Jowood разорвала отношения с Piranha Bytes и заказала Gothic4 в другой студии.
На этом примере мы можем наблюдать разностороннее движение: тяга к совершенству <-> необходимость завершения. Проанализируйте ситуацию.
Пример №3
Компания Electronic Arts считается одним из самых успешных издателей игр, даже в 2008-м они выпустили несколько безупречных хитов, например, их игра Spore по многим рейтингам признана лучшей по итогам прошедшего года. Но при этом EA считается весьма жестким работодателем. По некоторым приведенным в Интернете данным (точно не проверено, но об этом была написана весьма скандальная статья под авторством ea_spouse), текучесть кадров там составляла 50% в год из-за сверхурочной работы. Многие сотрудники были заняты по 90 часов в неделю. Система получила название "потогонной". Причем тут мы имеем две стороны одной медали. С одной — чем меньше человек в команде (ее костяке), тем оптимальнее она функционирует. Причем игроделы являются весьма увлеченными своей профессией людьми. С другой — авралы и перегрузки сказываются на эффективности работы коллектива. Успехи EA показывают, что их система является верной?
Назовите плюсы и минусы организаций с большой текучкой кадров.
Кристофер christopher@tut.by
Вообще есть много интересных аспектов, например, один из них ваш покорный слуга просто называет "феноменом тутбая". Как известно многим, портал раскрутился (приобрел популярность) на сервисе бесплатной электронной почты. При этом, когда он появился, уже было множество других схожих (mail.ru, yahoo и т.п.), байнет считался по существу частью рунета, да и само слово "байнет" тогда было только в кулуарном обиходе, большинство местных интернет-стартапов терпело фиаско, доступ во Всемирную Паутину у нас был и до сих пор является дорогим для обывателя, общая картина напоминала болото. На моей памяти "тутбай" никогда не раскручивался под эгидой "купляйце беларускае", в общем… тут есть много необъяснимых моментов. Хотя очевидно, что был правильно выстроен маркетинг, а его не стоит равнять с функциональностью отдела продаж (как часто путают), поскольку маркетинг практически всегда работает по схеме "один ко многим". Со временем портал стал для очень большого количества людей точкой входа в Интернет, и это уже перевело его на другой уровень, то есть дало новые возможности, которые можно использовать. Это не совсем новая схема функционирования информационных услуг, потому как по такой же работают телевизионные каналы и радиостанции.
Приведем недавний пример с "движением по методике", но при этом почти провальным. MMORPG (для тех, кто незнаком с данной терминологией, эта аббревиатура обозначает ролевую игру в режиме онлайн — одно из самых популярных современных течений) Age Of Conan, созданная по мотивам небезызвестных произведений Роберта Говарда, достаточно хорошо себя разрекламировала, к тому же первый месяц своего существования объявила бесплатным с точки зрения регистрации. Конечно, пользователи повалили туда толпами, миллион набрался очень быстро. Многие даже стали говорить о предстоящей серьезной конкуренции с известнейшей World of Warcraft. Но после того как "бесплатное закончилось", отток оказался чуть ли не фатальным. Виртуальный мир Age Of Conan практически опустел. У продукта оказалось мало зацепок, которые бы сохранили пользовательскую массу в рамках проекта. Это лишний раз доказывает, что все структуры команды должны работать взаимосвязано, как вариант, на равноправном принципе с высокой степенью ответственности.
***
Итак, сегодня в рамках обсуждения организации бизнес-процессов мы продолжим рассмотрение каркасов Microsoft Solutions Framework (MSF). Напомним, что это набор из шести моделей: архитектуры предприятия, управления рисками, команды, процесса, приложения и процесса проектирования. Они предусматривают набор правил и спецификаций при создании и распространении программных продуктов плюс обеспечивают более эффективное использование технологий для решения проблем бизнеса.
В принципе, этот материал, как и предыдущий, мы разделим на две части, то есть в одной рассмотрим некоторые вопросы, в данном случае касающиеся MSF, а потом перейдем к общей части обсуждения. Причем сразу договоримся о том, что MSF — это не единственная методология, которую мы будем рассматривать, потому как вариантов несколько. Причем события последних лет многое видоизменили, ИТ-сектор достаточно турбулентен. Конечно, до марксистских экономических моделей мы не дойдем, хотя можем рассмотреть управляемую динамику Джона Нэша. А сегодня в рамках MSF мы обсудим модель команды (Team Model). В ней, кстати, также есть "запах социализма":).
Team Model
Изначально нужно определиться с важнейшими целями проекта. Среди них выделены следующие.
. Выполнение требований заказчика (пользователей).
. Соответствие проектным ограничениям.
. Соответствие спецификациям, которые основаны на требованиях заказчика.
. Выявление и устранение недоработок.
. Повышение эффективности труда пользователей.
. Корректная установка и сопровождение.
Вот такие шесть пунктов, достаточно абстрактных на первый взгляд. Но на самом деле они подразумевают правильный подход к делу. Например, первым пунктом идет не выполнение проекта в срок или укладывание в бюджет, а выполнение требований заказчика. Если заказчик (или же группа пользователей) недоволен, то проект нельзя назвать успешным.
Второй пункт касается проектных ограничений, в число которых входит соблюдение сроков и установленного бюджета. Здесь все понятно.
Третий пункт касается конкретики в договоренностях между разработчиками и заказчиком, что подразумевает составление подробной функциональной спецификации, детально описывающей продукт. С одной стороны это защищает разработчиков, потому как они выполняют все "по бумажке", а с другой, по этой же "бумажке" заказчик может требовать. То есть, самое главное в этом — конкретика во взаимоотношениях.
Пункт насчет выявления и устранения ошибок/недоработок стандартен. Конечно, желательно все учитывать и исправлять заранее. Для этого необходимы тестеры.
Повышение эффективности труда пользователей… В прошлом материале мы спросили вас о том, насколько эффективным для вас, ваших знакомых или сотрудников является переход на Windows Vista и новый Office. Так вот, расшифровывая данный пункт, представители Microsoft изначально говорят о том, что продукт может быть признан в пользовательском сообществе только в том случае, если позволяет работать эффективнее, иначе — провал. Честно сказать, я не совсем понял прикол с "резиновой лентой" в новом Office, которая оказалась не такой уж и удобной, также возникли проблемы с форматом *.docx, который не имеет широкого хождения, а плюсы его использования не так очевидны. В общем, с моей точки зрения, это и есть тот провал (по сравнению с Office 2003), о котором написано. Хотя могу и ошибаться, причем в данном случае имеется в виду несколько другой момент — пользователей нужно и убедить в эффективности применения продукта.
Корректная установка и сопровождение. В данном случае речь идет о том, чтобы программа инсталляции вела себя корректно и без ошибок, потому как это первое впечатление. Плюс к этому немаловажную роль играют сопровождение и техническая поддержка продукта.
Но фишка не в этом, а в том, что данные шесть пунктов подразумевают шесть ролей в коллективе соответственно указанным выше пунктам. . Product management. Управление продуктом.
. Program management. Руководство программой.
. Development. Разработка.
. Testing. Тестирование.
. User education. Обучение пользователей.
. Logistic management. Управление материально-техническим снабжением.
Теперь о социализме. Дело в том, что все шесть ролей, соответствующих целям, равноправно влияют на успешность продукта, то есть единоначалие здесь отсутствует. Работа каждого сотрудника зависит от работы другого. Естественно, это повышает уровень ответственности каждого. Причем в современных реалиях достаточно бурно обсуждается эффективность существующих моделей поощрений (что, кстати, не указано в описании MSF Team Model). Например, вариант неравноправия часто может сработать в минус для эффективности работы коллектива. Продукт — это результат работы команды.
Сама модель, представленная в рамках MSF, является достаточно гибкой и подразумевает повышение эффективности. Team Model существует с плотной привязкой к Process Model, о которой мы поговорим в следующем материале, поскольку тема достаточно обширна.
Вопросы для обдумывания
Мы продолжим тенденцию обсуждения реальных примеров из жизни. Итак…
Пример №1. 1999-й и Delphi
Одна местная компания в 1998-1999 гг. взялась за разработку достаточно крупного проекта, связанного с переводом сложной программной оболочки из ДОСовского интерфейса в Windows. Вся соль ситуации заключалась в том, что все делалось в Borland/Inprise Delphi 4 с использованием новых технологий данной среды разработки. Произошла интересная катавасия, поскольку программная оболочка предварительной версии просто не загружалась на ноутбуке у заказчика. Ситуация оказалась в итоге экстремальной, поскольку это была ошибка… внутри Delphi с поддержкой Intel'вских процессоров (наверняка многие помнят этот момент, поскольку об этой ошибке было заявлено официально и много писали). Вот это действительно форс-мажор. Вариантов развития ситуации было несколько, а именно: переписать все в другой IDE, например, в C++ Builder, или же ждать исправлений со стороны Borland, доведя разработку до конца, а в документации временно указать на наличие существующей ошибки. Пошли по второму пути. Причем заказчик не разбирался в тонкостях и в дальнейшем к услугам данной фирмы уже не обращался. И вообще, об этом моменте оба хотели бы забыть. А как в этой ситуации на месте разработчиков поступили бы вы?
Пример №2
Gothic3… Пожалуй, самый глобальный и сильный игровой проект, даже если смотреть с позиций нынешнего, 2009 года. Огромный виртуальный мир, нелинейный сюжет, множество городов и NPC, одних диалогов около 700 страниц. Специфика игрового рынка состоит в том, что в качестве заказчиков выступают издатели, а главное их требование — соответствие срокам, хотя к таким играм, как Gothic, существует и особое отношение. Очевидно, что Gothic3 рассматривалась как прорыв, игра могла вполне рассчитывать на мировое первенство. Разработчики — Piranha Bytes (Pluto13 Gmbh), которые сделали и две предыдущие версии, издатель — Jowood. Продукт вышел сырым, содержал некоторые обидные ошибки, соответственно, не нашел того отклика среди пользователей, который ожидался. Понятно, что проект очень глобальный и не уложиться в сроки с ним проще простого. После третьей версии Jowood разорвала отношения с Piranha Bytes и заказала Gothic4 в другой студии.
На этом примере мы можем наблюдать разностороннее движение: тяга к совершенству <-> необходимость завершения. Проанализируйте ситуацию.
Пример №3
Компания Electronic Arts считается одним из самых успешных издателей игр, даже в 2008-м они выпустили несколько безупречных хитов, например, их игра Spore по многим рейтингам признана лучшей по итогам прошедшего года. Но при этом EA считается весьма жестким работодателем. По некоторым приведенным в Интернете данным (точно не проверено, но об этом была написана весьма скандальная статья под авторством ea_spouse), текучесть кадров там составляла 50% в год из-за сверхурочной работы. Многие сотрудники были заняты по 90 часов в неделю. Система получила название "потогонной". Причем тут мы имеем две стороны одной медали. С одной — чем меньше человек в команде (ее костяке), тем оптимальнее она функционирует. Причем игроделы являются весьма увлеченными своей профессией людьми. С другой — авралы и перегрузки сказываются на эффективности работы коллектива. Успехи EA показывают, что их система является верной?
Назовите плюсы и минусы организаций с большой текучкой кадров.
Кристофер christopher@tut.by
Компьютерная газета. Статья была опубликована в номере 16 за 2009 год в рубрике технологии
