Организация бизнес-процессов. Часть 4

Теоретически разницы между теорией и практикой нет, но на практике она существует
Йоги Берра

Буквально на днях встречал гостя из Москвы, спустились в метро, стали беседовать о том о сем, но в процессе гляжу, у моего знакомого глаза начинают вылазить из орбит. Причем он упорно смотрит на двух студентов, разговаривающих неподалеку. Прислушиваюсь… «Да нет, на Лексусе я не поеду, лучше взять что-нибудь из Audi, TT или A3» — «А ты на R7 никогда не ездил…». Обращаюсь к знакомому: «Чего ты удивляешься? Ребята Need For Speed обсуждают». Какое же у него было расслабление сознания после этого:).
В общем, реальность, она всегда интереснее. С нее и начнем.

Один молодой человек, 3D-моделер, с которым мы, кстати, познакомились через мои статьи в КГ, нашел себе заказ в Интернете, суть которого заключалась в том, что он должен был подготовить около 20 низкополигональных моделей монстриков и животных для небольшой игры, и за каждую из них заказчик платил по 150 российский рублей (это 4-5 баксов по нашему:)). Позвонил мне и спрашивает, стоит ли браться и работал ли я с таким? Лично мое мнение, если нужны деньги и есть время плюс владение вопросом, и это не причинит ущерб психическому или физическому здоровью, то вопрос риторический.

Причем иногда сталкиваюсь с обсуждениями этой серии материалов (но не ввязываюсь в них), где нередко можно встретить мнение о том, что бизнес- процесс — это фактически прикладная научная дисциплина, у которой есть свои понятия, терминология, большое количество аббревиатур (за которыми обычно скрываются очень простые вещи), плюс к этому множество программных продуктов и услуг по автоматизации, опять же со своей терминологией. В общем, «хочешь разбогатеть — создай свою религию». Укоряют: об этом нельзя так вольно говорить/писать (а вдруг догадаются?:)). При этом большинство оппонентов, как бы это сказать - у них на работе есть процесс, но нет бизнеса. Поэтому такие нападки считаю несерьезными, а также считаю, что очень многое зависит от личностей, а само развитие идет по эволюционному закону.

Вернемся к случаю с моим знакомым. Итак, он без оглядки (молодой и горячий) бросился на амбразуру. Знаете, сколько он сдавал эти модели со всеми переделками? Два месяца. А когда мы с ним встретились, он еще и сказал, что 20 было выбрано из 70, все модели нужно анимировать, делать для каждой спецэффекты, и все за те же деньги. Спрашиваю: «А ты согласовывал план работ, техническое задание? Да?... Нет???... Вы вообще об этом говорили?» — «Ну, так, списались, я показал свои работы, ему понравилось…» — «А как тогда формировалась цена?». То есть ситуация схожа с тем, что я описал, говоря об оппонентах. Молодой энтузиаст с увлечением ухватился за процесс, но совсем забыл о бизнесе. В результате был сломлен психологически, износился физически и так далее. А работал за «шорох орехов».

***

Есть и другая сторона медали, когда бизнес в перспективе есть, а процесс привязывается к нему с трудом. Например, в начале этого года сразу в нескольких портфолио абсолютно незнакомых мне людей ваш покорный слуга нашел свои работы по архитектурной визуализации в 3D. Дело в том, что я их некогда разместил для участия в конкурсе на одном из дизайнерских специализированных сайтов, иностранном, с иностранным же псевдонимом-ником, но в качестве страны указывалась все-таки Беларусь. Сначала я не стал скандалить и банить этих персонажей, решил проследить за поведением одного из них. Естественно, у портфолио есть ссылка, а пронаблюдать, где она указывается, технически абсолютно несложно. Так вот, исследуемый индивид получил неплохой заказ и начал в Интернете искать исполнителей, ссылаясь на то, что сам не успевает, или просто прикидываясь заказчиком. Если бы у нас было так много свободных 3D-моделеров, профессионально владеющих вопросами архитектурной визуализации, то все прошло бы гладко. Судя по всему, кто-то откликался, но уровень не доходил до портфолио (в котором, кстати, были другие известные в кругах моделеров работы, вернее, он взял первые десять мест из проводимого конкурса:)). Ситуация меня насмешила через несколько дней, но перед тем, как я намерился написать и запретить. Почему насмешила? Он мне сам написал, предложив работу...

Запрос: «Вы умеете моделировать реальные архитектурные объекты?». Прикидываюсь идиотом: «Думаю, что да, а как это должно выглядеть?»… Присылает ссылку на портфолио. Отвечаю: «Ну, если так, то несложно. От вас требуется оформленное предложение, ТЗ, полное описание, без предоплаты не работаю…». Естественно, его возмутил вариант с предоплатой, он и пишет: «А у вас есть примеры каких-нибудь работ, чтобы мы могли посмотреть?» (обращался от «мы», представляясь небольшой фирмой). Пишу: «Конечно, вы можете посмотреть на мои работы, они у вас в портфолио, а именно: av030012.jpg, av030017.jpg, av030003.jpg, av030022.jpg, av030014.jpg, p031.jpg, av0601.jpg и av011212009.jpg». Далее молчание, хотя эти файлы были изъяты, а в сентябре пришло письмо: «Извините, это Валентин, который у вас украл работы для своего портфолио в марте. Не могли бы мы с вами начать сотрудничество на нормальных правилах взаимодействия?». Чем меня заинтересовал этот случай? И почему я не стал поднимать панику еще тогда? Очевидно, что человек достаточно деловой и ушлый, например, он смог находить заказы в условиях кризиса, но у него не пошел процесс так, как он рассчитывал. То есть оказалось, что в русскоязычном сегменте не так много свободных 3D-моделеров, владеющих конкретным вопросом. Кстати, я знаю много примеров проектов, на которые изначально находились деньги, но они не были реализованы в силу отсутствия профессиональных кадров. Причем сейчас мы говорили о достаточно тривиальных ситуациях, но многие программисты, искавшие или ищущие работу, довольно часто сталкивались с тем явлением, что в вакансиях требуется опыт работы по какой-нибудь новейшей технологии. Например, около трех лет назад я очень удивился запросу на программиста по Flex с двухлетним опытом, в начале этого года — «с опытом разработок под Android от одного года». А все это происходит точно так же, как и у вышеупомянутого Валентина. Есть заказы на новые технологии, причем на них очень легко выиграть тендер (легче, чем на стандартные системы С++/С# и т.п.). А после того как все с заказчиками согласовано, начинается поиск специалистов, и тут уже свистопляска… «требуется водитель с опытом вождения болидов «Формулы-1», фуникулеров и бронетанковых машин пехоты…».

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

***

Теперь мы продолжим, а вернее, уже закончим рассмотрение моделей Microsoft Solutions Framework (MSF) и обратимся сегодня к Design Process Model (модель процесса проектирования). Сразу скажем, что пропустили Application Model (модель приложения), потому как она подразумевает уж очень формальный подход. В общем, MSF — это рекомендательный набор каркасов, правил и спецификаций, применяемых при создании и распространении программных продуктов, а также для использования технологий для повышения эффективности бизнеса. Application Model — это просто описание, какими бывают структуры программных продуктов («N-уровневые», «клиент-серверные» и т.п.). Это вы можете прочесть практически в любой книге.

Design Process Model

Design Process Model также достаточно формальна. Она описывает основные этапы проектирования, которых три:
. Концептуальный проект.
. Логический дизайн.
. Физический дизайн.

Разбиение достаточно условно, потому как на практике вы можете по-другому выстраивать процесс.

Итак, на уровне концептуального проекта пишутся сценарии согласно требованиям заказчиков, в качестве которых могут быть обычные пользователи, предприятия и т.п. Думаю, что останавливаться на этом подробно нет необходимости.

Уровень логического дизайна осуществляется проектировщиками, которые составляют некую абстрактную модель программного обеспечения, то есть предлагают решение, в котором описываются все ключевые модули, варианты их взаимодействия, применяемые технологии. Здесь же определяются службы, делаются прототипы пользовательских интерфейсов, описывается логическая структура базы данных. Главной задачей данного уровня является определение основных служб системы (служба — набор процессов, совместно работающих над решением какой-либо задачи).

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

. Модульность.
. Абстрагирование. На данном этапе нужно иметь способность грамотно систематизировать работу с элементами (выделять и систематизировать главные их особенности).
. Инкапсуляция. Каждый объект/программа/подпрограмма/функция должен быть хорошо упакованным «черным ящиком», у которого для внешнего использования есть только входные и выходные параметры.
. Сильное сцепление и слабая сочетаемость. Объясню на примере. Системный блок вашего РС включает процессор, материнскую плату, винчестер, оперативную память, HDD, блок питания, корпус и т.п. Сами по себе эти элементы ничего полезного сделать не могут, но в сцеплении дают «системный блок» — один модуль. К нему вы можете подключить фактически любой современный монитор — другой модуль, независимо от технологий (ЭЛТ, ЖКИ), производителя и т.п. То есть у системного блока и монитора слабая сочетаемость — и тот, и другой можно поменять, да и коммутируются они между собой просто. При этом многие могут намекнуть, что такое же можно сказать и о комплектующих системного блока, представив каждое из них как отдельный модуль… Но нет. Под каждый процессор подойдет только определенный спектр материнских плат, а под них и их схемотехнику выбирается тип оперативной памяти, видеоплата (PCI, PCI-E, AGP). То есть здесь как раз таки наоборот, сильная
сочетаемость.

. Отделение интерфейса от реализации. Если объяснять на простом примере… Системный блок может иметь абсолютно любой дизайн корпуса, но внутри его — компьютер, выполняющий определенные функции. Или более очевидный пример: у вас сломался мобильный телефон, вы переставляете SIM’ку в другой, и основная работоспособность сохраняется, то есть вы можете звонить, принимать звонки и т.п. Причем у другого телефона может быть иная схемотехника, дизайн, операционная система, но вам даются экран, кнопки и ПО (интерфейс между вами и устройством), а с поставщиком сотовой связи идет общение по его технологиям (интерфейсы между устройством и поставщиком). В данном случае все очень просто объяснено. Мы когда-то рассматривали этот вопрос подробно, обсуждая COM-объекты в материалах по разработке компьютерных игр под Direct3D.

Переходим к следующему уровню.
Физический дизайн — это еще не реализация. Напомним, что Design Process Model подразумевает именно процесс проектирования, не более того. Так вот, физический дизайн — это уже техническая детализация логического дизайна, приспособление оного к реальным технологиям, написание спецификаций, описание физической структуры баз данных. То есть это уже практически ТЗ для программистов (но еще не оно!). Причем физический дизайн программистами же и делается.
Design Process Model является встроенной в Process Model, а именно, стоит между двумя его этапами: «Постановка задачи согласована» ->>> «Постановка задачи утверждена». То есть, если на уровне физического дизайна выясняется, что реализовать задуманное невозможно, то постановка задачи не утверждается.
Поэтому вариант «Постановка задачи согласована» ->>> «Постановка задачи утверждена» может циклично повторяться, пока все условия не будут удовлетворены. В принципе, это напоминает водопадный принцип работы, когда движение идет от точки к точке. А по существу все верно. Стоит отметить, что логический и физический дизайны по времени идут параллельно друг с другом (с небольшим опережением логического) и стартуют сразу после того, как появляется что-то на уровне концептуального проекта.
И как всегда, по традиции, предлагаю вам реальные ситуации для самостоятельного обдумывания…

№ 1

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

Но, допустим, ваш покорный слуга позарился бы на эти деньги и потом смело и немигающим взором наблюдал бы танец «умирающего лебедя». Теперь поставьте себя на мое место при таком повороте событий, а вернее, смоделируйте постановку задачи, составьте самостоятельно концептуальный проект, логический дизайн и физический дизайн.

№2

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

В общем, над чем предлагаю поразмыслить… допустим, вы решили самостоятельно написать подобный алгоритм именно для экономической сферы. Например, программа будет вычислять:
1. Эффективность открытия ресторана.
2. Равномерность распределения школ или детских садов.
При этом усилим алгоритм, а именно, программа должна выяснить оптимальное расположение в рамках имеющейся ситуации. То есть будет рекомендовать. Продумайте основные входящие данные-параметры, которые важны для ее функционирования. Расставьте весовые коэффициенты их влияния.

№3

И последний пример-задание, на который натолкнула интересная акция по продаже маек «IH8 Office 2007», развернутая одним предприимчивым офисным работником (H8 — это сочетание, читаемое как «hate», то есть «ненавидеть»). Действительно, мало кому понравились видоизмененное меню-«резиновая лента» и навязываемый переход на новый формат файлов *.docx.

Допустим, через два года перед вами поставят задачу написать текстовый редактор, причем имеется два конкурента — монструозный Word и бесплатный Open Office. Понятно, что дело не перспективно (хотя…), поэтому рассматриваем задачу гипотетически. В общем, что в данном случае могли бы предложить именно вы?

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

Рассказав пример с 3D, я понял, что иллюстрацию мне лучше смоделировать, а не нарисовать:). ОК. На данной 3D-модели показана Process Model (модель процесса) MSF с выделением Design Process Model (модель процесса проектирования). Модель процесса построена по смешанному типу. То есть, итерация от постановки задачи до выпуска идет по водопадной схеме от пункта к пункту, в каждом из которых есть точки согласования. В них разработчики решают: можно ли двигаться дальше или нет. Но при этом сама модель процесса — спираль. Другими словами, вы выпустили продукт, после чего по такой же схеме осуществляете его обновление. Модель процесса проектирования обусловливает процесс между пунктами «Постановка задачи согласована» и «План утвержден». К чести Microsoft, стоит отметить очень важный момент их структуры модели процесса, а именно, львиная часть работы над проектом — это планирование, проектирование и т.п. Кстати, я уже приводил подобные примеры, например, некоторые профессиональные разработчики игр могут от нескольких месяцев до полугода заниматься только планированием/проектированием, затем идет постановка ТЗ, а уже после этого — разработка.

Кристофер christopher@tut.by