Ориентация на потребности пользователей, получение от них отклика, фокус на доставке продукта, удобного для них, вовлечение их в процесс выявления требований и прочие очень правильные (а может и не очень) вещи зачастую являются залогом успешной реализации проекта. Но что, если это не всегда так?
Публикуя статьи о факторах успеха проектов, мы довольно часто стали сталкиваться с тем, что статистика — это всего лишь одни цифры, деленные на другие и умноженные на 100%, а вот общение со специалистами и их опыт — это куда более полезные и интересные вещи. Мы обратились к двум специалистам — программисту и аналитику -, которые имеют опыт работы на проектах различного масштаба, которые не раз работали в одной команде и попадали в не самые приятные ситуации. Мы решили спросить, бывало ли такое, что слово НЕТ помогает вести проект куда больше, чем следование перечисленным выше человеко-ориентированным принципам? Как вы думаете, каков был ответ? Ответом аналитика стало, что конечно бывало, еще и чаще, чем слишком сильное вовлечение пользователей в работу и зеленый свет для полной свободы их действий. В качестве примера: проекты внедрения информационных систем, в которых такое сплошь и рядом. Почему? Все, на самом деле, очень просто, и никакой магии в этом нет. Дело в том, что проекты внедрения информационных систем подразумевают под собой несколько ключевых шагов:
- Анализ текущей системы бизнес процессов: смотрим, как компания работает сейчас.
- Понимаем, что в данный момент компания методологически работает некорректно: подгон одних показателей под другие для того, чтобы сошлась отчетность за какой-нибудь период или еще какие-то неожиданные сюжетные повороты являются вполне нормальной ситуацией. Бывает так, что внедрение информационной системы было изначально запланировано для того, чтобы правильно поставить учет деятельности с точки зрения документации и этот учет оцифровать в системе.
- Проводим реинжиниринг процессов и ставим корректный учет для начала на бумажках.
- Моделируем новые процессы в типовом программном продукте. Если реинжиниринг проведен, то процентов на 90 можно брать типовое решение без всяких доработок, потому что вести стандартный учет оно уже умеет.
- Делаем на остальные 10% оставшихся особенностей доработки, тестируем, и так далее (речь сейчас не совсем о жизненном цикле этого проекта).
А теперь представьте, имея некорректные процессы у клиента, не перейдя к пункту 3, мы даем полную свободу пользователям формировать требования к системе, чтобы она соответствовала требованиям текущих не совсем правильных бизнес процессов. К чему приведет?
- Учет все еще некорректный.
- Доработка системы очень дорогая.
- Система может отказаться работать, если увлечься внедрением в нее неправильного учета.
- Клиент не сможет работать с новой системой, так как продолжит подгонять цифры как делал это раньше, чтобы сошлась отчетность, только вот в системе это сделать сложнее.
Вот вам и аналитические причины того, что иногда требования к системе лучше доверить команде внедрения, а не пользователям. Конечно, свои причины такого подхода к требованиям есть и у разработчиков. Однако об этом мы расскажем в нашей следующей статье.
Читайте далее 2 ЧАСТЬ
