Менеджмент цифрового мира - страница 11

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

Все это определило успех Agile, сначала он завоевал небольшие компании, а в конце нулевых пошел в крупные компании и IT-отделы корпораций. К тому времени, помимо Scrum был Kanban, гибридный Scrumban, и еще ряд методов и практик, несущих больше IT специфики и потому менее известных (XP, FDD, TDD, DDD и другие).

По мере того, как IT все больше входило в жизнь компаний и обеспечивало их бизнес-процессы, произошел следующий сдвиг рамки проекта: результатом проекта должно быть не просто разработка и внедрение софта, а решение в результате внедрения конкретных бизнес-задач и достижение возможностей бизнеса, при чем достижение результатов определяется не формальными критериями, а удовлетворенностью стейклолдеров. Принципиально изменился характер задач, которые бизнес ставит перед IT: не «разработать конкретный набор фич», а «доработать продукт так, чтобы доля занимаемого им рынка в Латинской Америке возросла с 3 до 7%», не «внедрить новую систему управления складом», а «добиться вместе с логистиками, чтобы пропускная способность склада в пиковую нагрузку увеличилась вдвое». И это по времени совпало с развитием интернет и ориентацией для продукты для конечного пользователя, а не для компаний, что вызвало свое семейство методов ведения проектов, основанных на User Experience. Которые, кстати, сейчас становятся актуальными и в других отраслях. Эта культура пока не имеет общего названия, потому что она не осознается как нечто цельное. Однако, составляющие ее концепты широко известны: UX, продуктовый подход, DevOps. Поэтому на слайде она просто обозначена как «Новое время».

Таким образом, каждая культура имела свои представления о том, что такое хороший проект и качественный продукт, которые кратко отражены выше на схеме. Но самое главное отличие возникает, когда что-то пошло не так, когда в ходе разработки оказалось, что проект невозможно сделать в запланированные сроки и бюджеты, или что разрабатываемая система не будет решать ту задачу, которую на нее возлагали. Культуры регулярного менеджмента предлагают заказчику смириться: НИОКР – потому что всякие исследования и конструкторские работы могут быть окончиться неудачей, а RUP – потому что заказчик ведь сам согласовал то задание, которое было выполнено и возможные риски. Естественно, исполнитель всегда готов открыть новый проект и попробовать еще раз решить задачу с учетом полученного опыта. Но после оплаты ранее сделанного, а процесс устроен таким образом, что неудача обнаруживается близко к завершению. Типичная ситуация в IT – когда после того как бюджет израсходован на 90% выясняется, что задача сделана наполовину, и надо еще столько же. И так – несколько раз. Agile не дает гарантии результата, но в нем это явно оговорено, в то время, как регулярный менеджмент результат обещает. Однако он предлагает заказчику постоянно следить за движением проекта и корректировать направление, чтобы прогнозы становились более реалистичными. А еще – начинать с зон наибольшей неопределенности, а не откладывать их на потом, чтобы, встретив там существенные трудности, заказчик мог быстро свернуть проект – это принцип Fail fast. А современные подходы, помимо раннего обнаружения проблем и культуры постоянных экспериментов и проверки гипотез нацелены на партнерство IT и бизнес-заказчика в решении проблем и достижении возможностей.