Моделирование и прототипы масштабных решений

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

Кто-то, возможно, попытается привести контр-пример Сбербанка, где
« …запустили крупнейшую в России Agile-трансформацию, которая насчитывает 11000 сотрудников, 20 трайбов и более 1200 Agile-команд… »,
но достаточно немного присмотреться к тому, что собой представляет Sbergile, чтобы заметить так называемый «overcommunication»: церемонии, планирование спринта, ежедневные стендапы, демонстрации, продуктовые синхронизации, ретроспективы, портфельные синхронизации, обзоры результатов трайба и т.д. – все это происходит в совокупности довольно часто на встречах разного состава. Хочется спросить: ребята, а работаете-то вы когда? Да никогда, просто, когда в банке 11 тысяч сотрудников ИТ, есть место как для говорунов, которые занимаются сберджайлом, так и для тех, кто действительно обеспечивает работу банка: межсистемную интеграцию, проверку клиентов и т.д., и т. пр.

А есть еще пользователи информационных систем банка, которым, несмотря на необходимость участия во всех этих сберджайловских церемониях, также нужно еще выполнять свои непосредственные функциональные обязанности, что приводит к переработкам – пользователи ИТ систем зачастую вынуждены уходить с работы после 22 часов.

А ведь можно было бы автоматизировать часть рутины на том же MS Office, чтобы сотрудники могли уходить с работы вовремя почаще. Для этого нужно обеспечить прямой контакт между конечным пользователем и программистом, минуя кучу прокладок. В результате непосредственного взаимодействия пользователя с программистом получится не корпоративное решение. Получится, скорее, временное решение.

Чтобы обеспечить плодотворное взаимодействие программиста непосредственно с конечным пользователем, программист должен обладать навыками и бизнес аналитика, т.е. уметь говорить с конечным пользователем на его языке и понимать предметную область пользователя. Это повышает стоимость программиста, но не повышает стоимость временного решения. И вот почему. Временное решение не нужно сдавать в поддержку крупной структуры, к нему нет тех требований, которые предъявляют к оформлению конечных продуктов корпоративного уровня. Т.е. при изготовлении временного решения экономится куча времени/денег благодаря отсутствию многих этапов.

Одна из задач временного решения является задача подготовки качественных тест кейсов для большого проекта корпоративного решения.

Чтобы обеспечить качество тест кейсов, необходимых для корпоративного решения, временное решение должно быть построено в интеграции с теми же системами, с которыми будет взаимодействовать постоянное корпоративное решение. Понятно, что здесь должны действовать некоторые ограничения на взаимодействие с тем, чтобы временное решение не «положили» одну или несколько корпоративных систем. Обычно, это запрет на запись и ограничение квот на чтение. В идеале – это работа с репликой боевого контура систем.

И, возможно, у кого-то возникнет вопрос: зачем нужно временное решение, если можно сделать постоянное? Зачем тратить деньги дважды на одно и то же?

Давайте попробуем разложить все по полочкам.

Задачи и цели временных решений

• Моделирование требуемых результатов. Документарное абстрактное описание требований пользователя (а так же бизнес процесса, функциональной спецификации, спецификации разработчика) обладает тем недостатком, что его нельзя протестировать иначе, как путем мыслительного сопоставления различных фактов и выводов, содержащихся в документе (документах), что трудноосуществимо. Пользователи в своей постановке задачи ошибаются довольно часто. Чтобы ошибаться реже нужен инструмент автоматической проверки постановки задачи или даже еще сырой идеи. Им нужно моделирование. Рабочий прототип решения позволяет проверить качество, как постановки задачи, так и ее решения на детальном уровне и на конкретных цифрах в автоматическом режиме.
• Повышение экспертизы в решаемых задачах проекта каждого участника проекта. Это пригодится при согласовании документов большого проекта.
• Снижение рисков неправильного проектирования и повышение качества корпоративного решения, которое будет построено по водопадной модели.
• Сокращение совокупного срока и стоимости разработки. Утверждение базируется на том, что большинство крупных водопадных проектов превращаются в дорогостоящие и долгоиграющие итеративные проекты из-за выявления концептуальных ошибок в конце пути, на этапе тестирования программного решения. При использовании модельного подхода вероятность возникновения концептуальных ошибок приближается к нулю, так как ошибки исправляются еще на этапе моделирования. Стоимость и сроки исправления ошибок на этапе моделирования на несколько порядков меньше, чем при следовании водопадной модели построения продукта.
• И, конечно, тест кейсы. Программа и методика испытаний большинства крупных проектов, в которых мне приходилось участвовать, практически всегда страдала низким качеством сценариев тестирования. Благодаря моделированию, тест кейсы можно делать в больших количествах с близким к идеалу качеством измеримых показателей.

Ответ на вопрос о том, как интегрировать множество связанных с точки зрения бизнес-процессов, но технологически различных систем, дан достаточно давно и используется в различных стандартах проектирования программных продуктов, таких, как DCOM, CORBA, SOA и т.д. Основная идея этого ответа заключается в том, что стандартизируются только интерфейсы обмена данными (сервисы), внутренний мир систем остается на усмотрение разработчиков этих систем. Древнеримское правило: «Разделяй и властвуй» - в действии.

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

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

Мой опыт создания рабочих прототипов всегда был связан с VBA и MS Office + иногда использовался какой-нибудь BI инструмент. Связано это с тем, что на этих продуктах действительно получается быстрее разрабатывать прототипы, чем на .Net ASP. Почему? Это тема для отдельной статьи.