|
Создание нового бизнес-процесса - огромная работа. Необходимо поставить цели, к которым вы будете стремиться, определить время и условия начала и окончания работ, вычленить отдельные задачи, определить контрольные точки и показатели, рассчитать бюджет. Наибольший успех сопутствует тем проектам, которые ведутся людьми, имеющими четкие представления о своем клиенте и сценарии использования создаваемого продукта. Это верно и в отношении проектов по формированию новых бизнес-процессов. Клиент может быть вне или внутри компании, суть проблемы от этого не меняется: как он будет использовать разрабатываемый продукт или процесс? Какие получит преимущества по сравнению с тем, что было прежде? Кроме того, необходимо добиться четкого понимания принимаемых компромиссных решений на каждом уровне руководства. Всякий проект состоит из множества компромиссов. Если говорить о разработке ПО, руководство всегда требует создать продукт с богатым набором функциональных возможностей и в то же время компактный, а сделать его нужно за одну ночь и с минимальными затратами. Большие начальники всегда хотят все сразу и сейчас, поэтому необходимо, чтобы они получили очень ясное представление о возможных и необходимых компромиссных решениях. Если вы считаете правильным наделить продукт дополнительными возможностями - пускай это и увеличит объем кода, - стоит заранее обезопасить себя от претензий со стороны вышестоящего руководителя, которому вдруг в самом конце работы может прийти в голову, что было бы лучше сделать что-нибудь попроще да покомпактнее. Очень неприятно бывает и когда менеджер из кожи вон лезет, чтобы удержать расходы в рамках установленного бюджета, а потом ему вдруг говорят, что не в деньгах дело - если надо, подкинули бы еще, - но в продукте всего должно было быть по максимуму. Все то же самое верно и в отношении работы по созданию электронного процесса. Необходимо проявлять гибкость с учетом меняющихся требований, но так, чтобы последующими корректировками не увести проект от исходных целей. Необходим ясный и прозрачный процесс оценки предлагаемых изменений и принятия решений, включая и возможный пересмотр постановки задачи.
Несколько лет назад выпуск новой версии операционной системы Windows NT чуть не пришлось отложить, когда все уже было готово к началу поставок. И вовсе не из-за какой-нибудь неожиданно всплывшей ошибки или просчета, допущенного на этапе разработки ПО, а из-за банальной картонной коробки. Проект дизайна упаковки лег на стол одного из ответственных за его утверждение в самый день ухода этого сотрудника в отпуск. И так там и валялся, пока не пришло время раскладывать комплекты по коробкам - а их-то и не оказалось. До начала поставок оставалось всего двое суток, а на изготовление упаковки в норме требуется десять дней. Только благодаря авральной работе производственников нам удалось получить достаточно коробок - едва просохших от краски, - чтобы отгрузить первую партию в назначенный срок. — 121 —
|