Организация бизнес-процессов. Часть 3
Сегодня после небольшого тематического отпуска мы продолжим рассмотрение вариантов организации бизнес-процессов. На предыдущие части пришло много откликов, теперь нашлось время на написание продолжения, поэтому будем развивать серию дальше. Приступим…
Есть одна тонкость, которой в свое время я дал название «феномена картошки фри». Купить в супермаркете ее проще, чем готовить самому, хотя есть разница в цене, вкусе и так далее. Я бы даже сказал, что существует разница и в качестве, при условии, что вы умеете готовить. Если нет, то магазинный вариант будет всегда лучше, и для вас он единственно верный, если вы без ума от картофеля.
«Феномен картошки фри» можно встретить везде. Прошло не так много времени со времен распада СССР и с тех пор, как мы начали перенимать целиком западные модели. Иногда эти модели годятся как корове седло, но других вариантов нет, потому как свое создавать сложнее, а иногда для этого и просто не хватает знаний и умений. Это не говоря о случаях, когда модели навязываются как единственно верные.
Когда в прошлых материалах серии мы говорили о наборе MSF (Microsoft Solutions Framework), предупреждали, что обсуждаем практически голые каркасы, носящие рекомендательный характер. Всегда нужно предусматривать специфику.
Эта серия материалов рассматривает больше практические аспекты, связанные с реальной жизнью, поэтому приведу небольшой пример.
Пример с фирмой
Отмечу, что сразу делать выводы не стоит, потому как мы будем рассматривать эту ситуацию через обобщающую модель процесса. Там результаты и выводы будут другими.
Несколько недель назад произошел интересный случай. Ваш покорный слуга решил более подробно изучить тему тестирования программных продуктов. То есть до этого я занимался, как называю, «специфическим» тестированием: участвовал как специалист в том или ином вопросе, находил слабые места, давал рекомендации. Потом подумал: «если я освоил часть профессии, то нужно довести все до совершенства».
Зашел в Интернет, попробовал найти какие-нибудь местные курсы в рамках фирм, которые занимаются практикой. Меня интересовали конкретные методологии, стандарты и программные «фишки». Оказалось, что одна крупная белорусская компания приглашает на такие курсы. Месяц назад я послал заявку, потом мне перезвонили, сказали: «Приходите завтра в 10.00 в комнату NNN». Пришел, но… тут столкнулся с чем-то невероятным, причем из другой сферы.
В общем, как оказалось:
. Пункт первый. Я пришел неправильно. На самом деле, мне не(!) нужно было быть в комнате NNN в 10.00, как я это сделал по договоренности. А на самом деле нужно было подойти к диспетчеру в вестибюле, который бы вызвал HR-менеджера, находящегося не(!) в комнате NNN. Логика и не булева, и не вероятностная. Как я люблю цитировать фразу из одного школьного задачника: «Для правильного решения требуемых данных нет, а приведенные — не нужны».
. Пункт второй. Выражение в моем письменном запросе: «Я хотел бы посещать ваши курсы» волшебным образом преобразовалось в соискание должности тестера в данной компании. Опять же: «Для правильного решения требуемых данных нет, а приведенные — не нужны».
. В итоге: мне дали типовой тест вместо курсов:), плюс втык от HR-менеджера по поводу того, «что она не должна бегать по зданию в поисках каждого…» чудака на букву «м» (это образно, а не дословно) и так далее.
И вот сижу я на тесте моих знаний по тестированию:))), лениво тягаю «резиновую ленту» офиса 2007, и думаю: в чем ошибка? Объявление о приеме на курсы висит на сайте этой компании до сих пор.
Сравнение
Если перевести это на программы, то я выступал в качестве клиента, компания — сервера. Ошибка не в протоколе обмена данными, а в работе сервера, который, между прочим, построен по шаблону структуры коммерческого предприятия.
Ошибки (баги) проявились в действиях HR-щика, согласованности работы подразделений. Во второй части материала мы рассматривали Team Model, где, по утверждению Microsoft, все члены команды являются равноправными, от успешности действий одного зависит работа других, а в результате — и команды в целом. Это не так. То есть, в идеале, конечно, так должно быть, но есть и другие законы.
В нашем примере часть серверного ПО не функционирует, но на работе самой фирмы (сервера) это существенно не отображается. Почему? Спиральный принцип бизнес-процесса. Его мы рассмотрим сегодня. А позже, когда уже не будем говорить об MSF, остановимся подробно на правилах доминанты.
MSF
Напомним, что базовый каркас MSF включает шесть моделей:
1. Enterprise Architecture Model. Модель архитектуры предприятия.
2. Risk Management Model. Модель управления рисками.
3. Team Model. Модель команды (модель группы).
4. Process Model. Модель процесса.
5. Application Model. Модель приложения.
6. Design Process Model. Модель процесса проектирования.
Их объяснение в кратком виде мы дали в первой части материала.
Process Model
Стоит сказать о традиционных подходах в рамках модели процесса (отображением гибкой методики управления проектом, его разработкой). В классическом варианте их два:
. Модель водопада (Waterfall Model).
. Модель спирали (Spiral Model).
В рамках MSF выделен третий:
. Смешанный, совмещающий элементы двух предыдущих.
В варианте «модели водопада» мы подразумеваем случаи, когда разработка ведется от точки к точке, что обычно присуще созданию несложных приложений, в которых все понятно заранее. Если объяснять простыми словами… Вы придумали программу, определили этапы ее разработки. На каждом остановочном пункте (выбранной опорной точке) производится оценка и вырабатывается решение о том, можно ли двигаться дальше.
У «модели водопада» есть плюс в том, что явно присутствует конечная точка. Она (эта модель) хорошо применима в случаях, когда постановка задачи ясна заранее и не предусматривается ее существенных изменений впоследствии. Это как нельзя лучше подходит для несложных продуктов. Например, вы хотите написать программу WinAmp, знаете, что она будет воспроизводить медиафайлы, определяетесь со стандартами и разрабатываете. При этом изначально вам необходимо будет готовить множество выверенной документации, определиться с этапами, процедурами оценки результатов. «Спиральная модель» является более гибкой и предусматривает итерации. То есть разработку можно представить как некий цикл, в котором повторяются процессы от постановки задачи до выпуска продукта. При каждой итерации, которую можно назвать обновлением версии, к продукту добавляются новые возможности и функции. Начинают с малого.
«Спиральная модель» больше подходит для сложных продуктов, особенно в случаях, когда появляются перспективы изменения первоначальных планов. Она удобна в самой архитектуре, потому как многие риски можно предусмотреть заранее, есть большая гибкость и меньшее количество волокиты с документацией. Среди недостатков «спиральной модели» можно указать явное отсутствие конечной точки. Пределу совершенства нет. В данном случае вспоминается известная шутка о том, что новая версия программы Nero все еще может записывать CD/DVD. Напомню, что изначально эта программа предназначалась только для этого, но потом было реализовано столько дополнительных функций и возможностей, что основная цель затерялась.
Пример
Приведем простейший пример. Наверное, многих отпугнет, что он игровой, но тут, по существу, неважно, что мы создаем, это могут быть и клиент- серверные приложения. Допустим, вы работаете один и решили создать игру, в которой танк должен ездить по игровому полю. Все выглядит просто. Как вы это будете делать? Большинство предусмотрит «водопадный принцип», то есть:
1. Сначала все опишете на бумаге, определив, что это будет конкретно. Причем все очень подробно, включая каждую мелкую деталь.
2. Составите план, выявив опорные точки последовательных действий. Например, определитесь, что сначала нарисуете танк, затем элементы карты, потом разработаете программу, в которой отобразите игровое поле, реализуете прокрутку. После поместите танк на поле. А далее идет реализация движения и управления мышью или клавиатурой.
3. Рисуете (создаете) танк.
4. Производите оценку соответствия задаче.
5. Создаете элементы карты местности (дороги, деревья).
6. Производите оценку соответствия задаче.
7. Пишете программу, помещаете в нее пока еще не размеченную карту. Реализуете прокрутку.
8. Производите оценку соответствия задаче.
9. Расставляете дороги, деревья и т.п.
10. Производите оценку соответствия задаче.
11. Размещаете танк на поле. Реализуете управление и анимацию движения.
12. Производите оценку соответствия задаче.
13. Продукт готов.
Причем, пункты 3, 5, 7 вы можете менять местами.
По «спиральной модели» предусмотрено другое движение:
1. Сначала все опишете на бумаге, определив, что это примерно будет.
2. Составите план разработки с учетом обновлений версий.
3. В первой версии создаете программу, в которой по полю, состоящему из идентичных элементов, передвигается квадратик, реализуете прокрутку экрана и управление квадратиком с помощью мыши и клавиатуры.
4. Производите оценку версии с учетом специфики.
5. Во второй версии меняете квадратик на танк.
6. Производите оценку версии с учетом специфики.
7. В третьей версии модифицируете карту (заменяете идентичные элементы).
8. Производите оценку версии с учетом специфики.
9. Улучшаете танк.
10. Производите оценку версии с учетом специфики.
11. Улучшаете карту.
12. Производите оценку с учетом специфики.
13. И так далее.
В данном примере «спиральная модель» выглядит лучше. Почему? Изначально вы работаете напрямую с «движком» (основной программой), внося дополнения в процессе, можете быстро выявлять недостатки. Плюс к этому вы все время имеете дело с работающей системой и мало возитесь с документацией. Все изменения и требования вносятся «по месту».
У «водопадной модели» другой плюс — изначальное задание конкретно. Если оно составлено без ошибок, причем подробно написано, например, указано, сколько модель танка должна занимать Кб или Мб, какие требования к цветам и раскраске, то есть все необходимые мелочи, — реализация пройдет гладко и быстрее. В большинстве случаев, при работе по такой модели вы будете иметь под рукой уже нарисованные кадры, сделанные при постановке и согласовании задачи. Они станут основным руководством к действию.
Важный аспект
Если вы работаете не на себя, а на заказчика, то «водопадная модель» лучше, потому как все условия согласовываются заранее и есть подробная постановка задачи. Данный вариант может иметь для заказчика только один минус в случаях, когда он захочет внести серьезные дополнения или обновить продукт.
На практике «спиральная модель» всегда располагает к привлечению заказчика в процесс разработки. Это тоже может иметь ряд минусов, но уже для вас. Например, когда я профессионально занимался аранжировками музыкальных композиций, то была огромная разница: делал я их у себя
самостоятельно или на студии рядом с заказчиками. В первом варианте мы все оговаривали конкретно, я производил продукт, отдавал его, на чем все завершалось. Во втором случае заказчики лезли внутрь процесса: тут поменять, а может, вернуть как было, или поменять инструмент... Дело затягивалось и завершения ему не было видно. В конце концов, более-менее конечный продукт всегда выглядел сырым. Производство должно быть максимально закрыто от заказчика, но при этом нужно показывать некоторые этапы для того, чтобы он знал: дело движется.
Хотя бывают и тонкости. Например, один мой знакомый любил звонить особенно достающим заказчикам, задавая вопросы по какой-нибудь мелочи типа: «Может быть, кнопку расположить чуть левее, как вы думаете?». И так до тех пор, пока его не посылали подальше, говоря: «Занимайся всем сам!». Хотя затем заказчики его пугались, предпочитая обращаться к другим.
У меня в ранней молодости была другая частая ошибка, схожая с этой, и имеющая место именно из-за спирального принципа процесса разработки. То есть я рассматривал программу как единый блок, а не поэтапный процесс с выверением состояния на каждой опорной точке. Написав приложение, я тут же отсылал его заказчику, потом замечал ошибку, отсылал наново с пометкой «исправлено», и так могло происходить несколько раз в день. Или же потом просто выкладывал программу в Интернете, постоянно обновляя ее. В результате заказчик вообще путался с версиями, не мог уследить за быстрыми изменениями. Из этого рождалось ощущение нестабильности продукта.
Правильно же действовать так…
Смешанный принцип
В рамках MSF в глобальном смысле рекомендован смешанный принцип, который подразумевает итерацию обновления по восьми пунктам, нечетные — фазы процесса, четные — главные опорные точки:
1. Постановка задачи.
2. Постановка задачи согласована.
3. Планирование.
4. План утвержден.
5. Разработка.
6. Цель достигнута.
7. Стабилизация.
8. Выпуск.
То есть движение 1->8 — «водопад», но если мы поместим его в цикл, то это уже будет «спираль». В главных опорных точках (2, 4, 6, 8) все подразделения синхронизируют свои действия. Эти точки демонстрируются заказчику. Для него они показывают жизнеспособность продукта, а для вас — жизнеспособность процесса обновления. Это не одно и то же.
Каждая фаза может делиться и на промежуточные опорные точки, которые предназначены для внутреннего пользования.
В варианте с моей ошибкой нужно было предусмотреть более объемный и бюрократический вариант обновления с ключевым итеративным пунктом «План утвержден».
В завершение
Большинство бизнес-процессов носят спиральный принцип развития: сегодня торгуешь компьютерами, завтра — компьютерами и ноутбуками, послезавтра — компьютерами, ноутбуками и игровыми приставками. Жизнеспособность бизнес-процесса определяется функционированием его ключевых модулей. Так или иначе, программу Nero всегда будут приобретать для записи дисков, а не из-за того, что там появился звуковой редактор или графический редактор для оформления обложек. Для этих целей есть программы и получше.
В самом первом примере фирма внедрила HR-менеджмент, он оказался плохо работающим, но это не сильно отражается на том, что данная фирма делает.
Продолжение следует…
Кристофер christopher@tut.by
Есть одна тонкость, которой в свое время я дал название «феномена картошки фри». Купить в супермаркете ее проще, чем готовить самому, хотя есть разница в цене, вкусе и так далее. Я бы даже сказал, что существует разница и в качестве, при условии, что вы умеете готовить. Если нет, то магазинный вариант будет всегда лучше, и для вас он единственно верный, если вы без ума от картофеля.
«Феномен картошки фри» можно встретить везде. Прошло не так много времени со времен распада СССР и с тех пор, как мы начали перенимать целиком западные модели. Иногда эти модели годятся как корове седло, но других вариантов нет, потому как свое создавать сложнее, а иногда для этого и просто не хватает знаний и умений. Это не говоря о случаях, когда модели навязываются как единственно верные.
Когда в прошлых материалах серии мы говорили о наборе MSF (Microsoft Solutions Framework), предупреждали, что обсуждаем практически голые каркасы, носящие рекомендательный характер. Всегда нужно предусматривать специфику.
Эта серия материалов рассматривает больше практические аспекты, связанные с реальной жизнью, поэтому приведу небольшой пример.
Пример с фирмой
Отмечу, что сразу делать выводы не стоит, потому как мы будем рассматривать эту ситуацию через обобщающую модель процесса. Там результаты и выводы будут другими.
Несколько недель назад произошел интересный случай. Ваш покорный слуга решил более подробно изучить тему тестирования программных продуктов. То есть до этого я занимался, как называю, «специфическим» тестированием: участвовал как специалист в том или ином вопросе, находил слабые места, давал рекомендации. Потом подумал: «если я освоил часть профессии, то нужно довести все до совершенства».
Зашел в Интернет, попробовал найти какие-нибудь местные курсы в рамках фирм, которые занимаются практикой. Меня интересовали конкретные методологии, стандарты и программные «фишки». Оказалось, что одна крупная белорусская компания приглашает на такие курсы. Месяц назад я послал заявку, потом мне перезвонили, сказали: «Приходите завтра в 10.00 в комнату NNN». Пришел, но… тут столкнулся с чем-то невероятным, причем из другой сферы.
В общем, как оказалось:
. Пункт первый. Я пришел неправильно. На самом деле, мне не(!) нужно было быть в комнате NNN в 10.00, как я это сделал по договоренности. А на самом деле нужно было подойти к диспетчеру в вестибюле, который бы вызвал HR-менеджера, находящегося не(!) в комнате NNN. Логика и не булева, и не вероятностная. Как я люблю цитировать фразу из одного школьного задачника: «Для правильного решения требуемых данных нет, а приведенные — не нужны».
. Пункт второй. Выражение в моем письменном запросе: «Я хотел бы посещать ваши курсы» волшебным образом преобразовалось в соискание должности тестера в данной компании. Опять же: «Для правильного решения требуемых данных нет, а приведенные — не нужны».
. В итоге: мне дали типовой тест вместо курсов:), плюс втык от HR-менеджера по поводу того, «что она не должна бегать по зданию в поисках каждого…» чудака на букву «м» (это образно, а не дословно) и так далее.
И вот сижу я на тесте моих знаний по тестированию:))), лениво тягаю «резиновую ленту» офиса 2007, и думаю: в чем ошибка? Объявление о приеме на курсы висит на сайте этой компании до сих пор.
Сравнение
Если перевести это на программы, то я выступал в качестве клиента, компания — сервера. Ошибка не в протоколе обмена данными, а в работе сервера, который, между прочим, построен по шаблону структуры коммерческого предприятия.
Ошибки (баги) проявились в действиях HR-щика, согласованности работы подразделений. Во второй части материала мы рассматривали Team Model, где, по утверждению Microsoft, все члены команды являются равноправными, от успешности действий одного зависит работа других, а в результате — и команды в целом. Это не так. То есть, в идеале, конечно, так должно быть, но есть и другие законы.
В нашем примере часть серверного ПО не функционирует, но на работе самой фирмы (сервера) это существенно не отображается. Почему? Спиральный принцип бизнес-процесса. Его мы рассмотрим сегодня. А позже, когда уже не будем говорить об MSF, остановимся подробно на правилах доминанты.
MSF
Напомним, что базовый каркас MSF включает шесть моделей:
1. Enterprise Architecture Model. Модель архитектуры предприятия.
2. Risk Management Model. Модель управления рисками.
3. Team Model. Модель команды (модель группы).
4. Process Model. Модель процесса.
5. Application Model. Модель приложения.
6. Design Process Model. Модель процесса проектирования.
Их объяснение в кратком виде мы дали в первой части материала.
Process Model
Стоит сказать о традиционных подходах в рамках модели процесса (отображением гибкой методики управления проектом, его разработкой). В классическом варианте их два:
. Модель водопада (Waterfall Model).
. Модель спирали (Spiral Model).
В рамках MSF выделен третий:
. Смешанный, совмещающий элементы двух предыдущих.
В варианте «модели водопада» мы подразумеваем случаи, когда разработка ведется от точки к точке, что обычно присуще созданию несложных приложений, в которых все понятно заранее. Если объяснять простыми словами… Вы придумали программу, определили этапы ее разработки. На каждом остановочном пункте (выбранной опорной точке) производится оценка и вырабатывается решение о том, можно ли двигаться дальше.
У «модели водопада» есть плюс в том, что явно присутствует конечная точка. Она (эта модель) хорошо применима в случаях, когда постановка задачи ясна заранее и не предусматривается ее существенных изменений впоследствии. Это как нельзя лучше подходит для несложных продуктов. Например, вы хотите написать программу WinAmp, знаете, что она будет воспроизводить медиафайлы, определяетесь со стандартами и разрабатываете. При этом изначально вам необходимо будет готовить множество выверенной документации, определиться с этапами, процедурами оценки результатов. «Спиральная модель» является более гибкой и предусматривает итерации. То есть разработку можно представить как некий цикл, в котором повторяются процессы от постановки задачи до выпуска продукта. При каждой итерации, которую можно назвать обновлением версии, к продукту добавляются новые возможности и функции. Начинают с малого.
«Спиральная модель» больше подходит для сложных продуктов, особенно в случаях, когда появляются перспективы изменения первоначальных планов. Она удобна в самой архитектуре, потому как многие риски можно предусмотреть заранее, есть большая гибкость и меньшее количество волокиты с документацией. Среди недостатков «спиральной модели» можно указать явное отсутствие конечной точки. Пределу совершенства нет. В данном случае вспоминается известная шутка о том, что новая версия программы Nero все еще может записывать CD/DVD. Напомню, что изначально эта программа предназначалась только для этого, но потом было реализовано столько дополнительных функций и возможностей, что основная цель затерялась.
Пример
Приведем простейший пример. Наверное, многих отпугнет, что он игровой, но тут, по существу, неважно, что мы создаем, это могут быть и клиент- серверные приложения. Допустим, вы работаете один и решили создать игру, в которой танк должен ездить по игровому полю. Все выглядит просто. Как вы это будете делать? Большинство предусмотрит «водопадный принцип», то есть:
1. Сначала все опишете на бумаге, определив, что это будет конкретно. Причем все очень подробно, включая каждую мелкую деталь.
2. Составите план, выявив опорные точки последовательных действий. Например, определитесь, что сначала нарисуете танк, затем элементы карты, потом разработаете программу, в которой отобразите игровое поле, реализуете прокрутку. После поместите танк на поле. А далее идет реализация движения и управления мышью или клавиатурой.
3. Рисуете (создаете) танк.
4. Производите оценку соответствия задаче.
5. Создаете элементы карты местности (дороги, деревья).
6. Производите оценку соответствия задаче.
7. Пишете программу, помещаете в нее пока еще не размеченную карту. Реализуете прокрутку.
8. Производите оценку соответствия задаче.
9. Расставляете дороги, деревья и т.п.
10. Производите оценку соответствия задаче.
11. Размещаете танк на поле. Реализуете управление и анимацию движения.
12. Производите оценку соответствия задаче.
13. Продукт готов.
Причем, пункты 3, 5, 7 вы можете менять местами.
По «спиральной модели» предусмотрено другое движение:
1. Сначала все опишете на бумаге, определив, что это примерно будет.
2. Составите план разработки с учетом обновлений версий.
3. В первой версии создаете программу, в которой по полю, состоящему из идентичных элементов, передвигается квадратик, реализуете прокрутку экрана и управление квадратиком с помощью мыши и клавиатуры.
4. Производите оценку версии с учетом специфики.
5. Во второй версии меняете квадратик на танк.
6. Производите оценку версии с учетом специфики.
7. В третьей версии модифицируете карту (заменяете идентичные элементы).
8. Производите оценку версии с учетом специфики.
9. Улучшаете танк.
10. Производите оценку версии с учетом специфики.
11. Улучшаете карту.
12. Производите оценку с учетом специфики.
13. И так далее.
В данном примере «спиральная модель» выглядит лучше. Почему? Изначально вы работаете напрямую с «движком» (основной программой), внося дополнения в процессе, можете быстро выявлять недостатки. Плюс к этому вы все время имеете дело с работающей системой и мало возитесь с документацией. Все изменения и требования вносятся «по месту».
У «водопадной модели» другой плюс — изначальное задание конкретно. Если оно составлено без ошибок, причем подробно написано, например, указано, сколько модель танка должна занимать Кб или Мб, какие требования к цветам и раскраске, то есть все необходимые мелочи, — реализация пройдет гладко и быстрее. В большинстве случаев, при работе по такой модели вы будете иметь под рукой уже нарисованные кадры, сделанные при постановке и согласовании задачи. Они станут основным руководством к действию.
Важный аспект
Если вы работаете не на себя, а на заказчика, то «водопадная модель» лучше, потому как все условия согласовываются заранее и есть подробная постановка задачи. Данный вариант может иметь для заказчика только один минус в случаях, когда он захочет внести серьезные дополнения или обновить продукт.
На практике «спиральная модель» всегда располагает к привлечению заказчика в процесс разработки. Это тоже может иметь ряд минусов, но уже для вас. Например, когда я профессионально занимался аранжировками музыкальных композиций, то была огромная разница: делал я их у себя
самостоятельно или на студии рядом с заказчиками. В первом варианте мы все оговаривали конкретно, я производил продукт, отдавал его, на чем все завершалось. Во втором случае заказчики лезли внутрь процесса: тут поменять, а может, вернуть как было, или поменять инструмент... Дело затягивалось и завершения ему не было видно. В конце концов, более-менее конечный продукт всегда выглядел сырым. Производство должно быть максимально закрыто от заказчика, но при этом нужно показывать некоторые этапы для того, чтобы он знал: дело движется.
Хотя бывают и тонкости. Например, один мой знакомый любил звонить особенно достающим заказчикам, задавая вопросы по какой-нибудь мелочи типа: «Может быть, кнопку расположить чуть левее, как вы думаете?». И так до тех пор, пока его не посылали подальше, говоря: «Занимайся всем сам!». Хотя затем заказчики его пугались, предпочитая обращаться к другим.
У меня в ранней молодости была другая частая ошибка, схожая с этой, и имеющая место именно из-за спирального принципа процесса разработки. То есть я рассматривал программу как единый блок, а не поэтапный процесс с выверением состояния на каждой опорной точке. Написав приложение, я тут же отсылал его заказчику, потом замечал ошибку, отсылал наново с пометкой «исправлено», и так могло происходить несколько раз в день. Или же потом просто выкладывал программу в Интернете, постоянно обновляя ее. В результате заказчик вообще путался с версиями, не мог уследить за быстрыми изменениями. Из этого рождалось ощущение нестабильности продукта.
Правильно же действовать так…
Смешанный принцип
В рамках MSF в глобальном смысле рекомендован смешанный принцип, который подразумевает итерацию обновления по восьми пунктам, нечетные — фазы процесса, четные — главные опорные точки:
1. Постановка задачи.
2. Постановка задачи согласована.
3. Планирование.
4. План утвержден.
5. Разработка.
6. Цель достигнута.
7. Стабилизация.
8. Выпуск.
То есть движение 1->8 — «водопад», но если мы поместим его в цикл, то это уже будет «спираль». В главных опорных точках (2, 4, 6, 8) все подразделения синхронизируют свои действия. Эти точки демонстрируются заказчику. Для него они показывают жизнеспособность продукта, а для вас — жизнеспособность процесса обновления. Это не одно и то же.
Каждая фаза может делиться и на промежуточные опорные точки, которые предназначены для внутреннего пользования.
В варианте с моей ошибкой нужно было предусмотреть более объемный и бюрократический вариант обновления с ключевым итеративным пунктом «План утвержден».
В завершение
Большинство бизнес-процессов носят спиральный принцип развития: сегодня торгуешь компьютерами, завтра — компьютерами и ноутбуками, послезавтра — компьютерами, ноутбуками и игровыми приставками. Жизнеспособность бизнес-процесса определяется функционированием его ключевых модулей. Так или иначе, программу Nero всегда будут приобретать для записи дисков, а не из-за того, что там появился звуковой редактор или графический редактор для оформления обложек. Для этих целей есть программы и получше.
В самом первом примере фирма внедрила HR-менеджмент, он оказался плохо работающим, но это не сильно отражается на том, что данная фирма делает.
Продолжение следует…
Кристофер christopher@tut.by
Компьютерная газета. Статья была опубликована в номере 34 за 2009 год в рубрике бизнес
