Бизнес-приложения развиваются. Их нужно развивать. Это очевидно. Но насколько быстро это можно и нужно делать?
Разумеется, в общем случае это извечный вопрос. Почти философский. На него нет единственного верного ответа. Точнее сказать, на него приходится отвечать все время. Жаль, что нельзя принять решение один раз и дальше всегда ему следовать.
В заголовке этой статьи объединены две стороны одного вопроса: допустимая скорость развития и необходимая скорость развития.
Первая сторона вопроса – это допустимая скорость развития бизнес-приложения. Если не рассматривать возможности самого поставщика, то она ограничивается способностью пользователей и специалистов переходить на новые версии продукта без потерь. Под потерями здесь понимаются в том числе и психологические трудности, возникающие из-за непривычности, из-за навязанной необходимости освоения нового, из-за смены рефлексов в текущей работе и т. д.
Разумеется, эти потери можно частично компенсировать различными методическими материалами, гладкостью перехода на новую версию (насколько это возможно) и т. д. Однако лучше всего такие потери компенсируются явными, очевидными для пользователя или специалиста преимуществами. Но, к сожалению, это не всегда получается.
Зачастую, например, новое воспринимается более удобным и эффективным не сразу, а только спустя некоторое время.
Иногда новое воспринимают позитивно только новые пользователи. Потому что оно более понятное. А понятность как раз и нужна в основном новым пользователям. Ведь пользователи, работающие давно, уже все изучили.
Но самый «тяжелый» случай, это когда новое не несет в себе немедленных ощутимых выгод для пользователей. Когда новое необходимо для решения некоторых стратегических задач, которые крайне важны для вендора, для специалистов, да и для самих пользователей в конечном счете тоже. Но пользователям трудно ощутить это «здесь и сейчас». Это будет проявляться постепенно. И по этой причине пользователям будет трудно заметить непосредственную связь изменений и трудностей перехода, происходящих сейчас, с полученной ими позже пользой.
Вторая сторона вопроса – это необходимая скорость развития бизнес-приложения. Она обуславливается десятками самых разнообразных тенденций и возможностей. Это и тенденции развития общества, и технологические тенденции, и, наконец, простое стремление «сделать лучше». Часто отдельные тенденции и направления развития противоречат друг другу, но это нормально.
Важной тенденцией является то, что изменения в самой жизни становятся более быстрыми. Как минимум в той ее части, которая влияет на IT.
Другим существенным аспектом, как кажется, является то, что подходы и тенденции в IT становятся менее догматичными. Индустрия IT стала меньше «ходить строем». Раньше, как правило, было понятно, что «современная программа должна иметь вот такой интерфейс», «современная архитектура должна выглядеть вот так». Теперь же в большинстве аспектов сосуществуют несколько параллельных подходов, конкурирующих друг с другом и дополняющих друг друга одновременно.
В этих условиях приходится ориентироваться уже не на основную массу пользователей, а на их авангард, который активно «разведывает» новые реалии: устройства, сценарии, подходы к работе системы и пр. А ведь новую возможность нужно по-хорошему не только реализовать, но и более или менее довести до практического использования. И получается, что нужно успеть сделать это все до того, как новая возможность станет крайне необходима. Потому что когда потребность в ней окажется актуальной не только для авангарда пользователей, но и для основных масс, создавать и выпускать новое решение будет уже поздно.
Разумеется, все вышесказанное – это общие слова. А на практике нам приходится принимать конкретные решения. Когда и как вводить существенные изменения в платформу? Когда делать новую редакцию прикладного решения и с каким уровнем инноваций? Какой способ перехода можно себе позволить? Насколько можно поменять интерфейс?
Конечно, эти проблемы стоят перед всеми поставщиками бизнес-софта, за которыми стоят хотя бы тысячи пользователей. Тем более они актуальны в нашем случае, когда речь идет о миллионах пользователей.
У этой дилеммы – развивать или подождать – есть еще один трудный аспект – вопрос стабильности и качества. Конечно, все мы знаем ответ папы-программиста на вопрос мальчика из известного анекдота: «работает – не трожь».
Если ничего не менять или менять не сильно, то гораздо проще обеспечивать стабильность и качество. А если развивать систему, а тем более развивать активно, то стабильность и качество обеспечить сложнее.
Но есть и другой, буквально обратный аспект. Часто без существенных изменений нельзя добиться существенного улучшения именно качества.
Например, в версии 8 мы по мере развития проводили полный рефакторинг крупных и ответственных механизмов. По сути мы писали их с нуля. Мы понимали, что без такой кардинальной меры, только исправляя ошибки и внося доработки, мы не сможем обеспечить необходимое качество и развитие системы.
Конечно, дело обстоит сложнее, когда для поднятия качества требуется перестроить не только внутреннюю архитектуру, но и модель, представляемую специалистам и конечным пользователям. Такое тоже встречается и при развитии платформы, и при развитии прикладных решений.
Разумеется, кроме повышения качества за счет переработки архитектуры, при быстром развитии системы требуется существенно больше усилий и на регулярные процессы: отладку, тестирование, исправление ошибок. Мы понимаем, что эти процессы нам требуется существенно улучшать. Как минимум потому, что требования к качеству объективно повышаются.
Когда мы обсуждаем с пользователями и партнерами эти проблемы, то, конечно, получаем прямо противоречивые оценки и рекомендации. Тут, в общем, по-другому и не может быть. От «зачем вы так быстро развиваете» до «когда же вы, наконец, реализуете…». И мы понимаем, что это не разные мнения разных людей. Просто в каждый конкретный момент у человека больше «болит» (волнует, вызывает проблемы) или одна, или другая сторона проблемы.
Еще есть такое наблюдение, которое, к сожалению, трудно проверить. Некоторый аспект в технологии или прикладном решении может быть не востребован сейчас конкретными пользователями и специалистами, но ценен для них самим наличием возможности.
Например, возможность реальной удаленной работы, или работы через браузер, многими пользователями и даже специалистами не воспринималась как что-то необходимое. До тех пор, пока эта потребность не коснулась остро именно их. Но многие специалисты понимают, что наличие в их арсенале такой возможности защищает их от критической ситуации, когда от наличия этой возможности зависит успех всего проекта. Ведь хорошо, когда «пользователям понадобилось, а у нас это уже есть».
Еще одним важным моментом является гладкость миграции с предыдущих версий. Те, кто плотно работает с платформой «1С:Предприятие», могли заметить, что в последнее время мы все больше вкладываемся в гладкость миграции. Мы понимаем, что суммарная ценность (стоимость, важность) приложений, разработанных на «1С:Предприятии 8», огромна.
Сначала у нас была просто конвертация. Потом мы ввели понятие режима совместимости, в котором новая платформа эмулирует работу старой во многих аспектах. Иногда эмуляция выполняется «параноидально», воспроизводя даже ошибочное поведение старой версии, чтобы не изменилось поведение приложения.
Потом мы реализовали даже изменение структур данных при смене режима совместимости. То есть новая версия умеет «проворачивать фарш обратно»: восстанавливать старую структуру данных при необходимости экстренного отката на предыдущую версию.
А в версии 8.3.3 мы, кроме прежнего режима совместимости, сделали еще два новых отдельных режима совместимости. Режим совместимости интерфейса (можно использовать старый интерфейс или новый «Такси») и режим использования модальности (можно работать как раньше или отключить использование модальности – рекомендуемый режим). Таким образом, теперь разработчик может переводить свои приложения на новую версию постепенно и может откатываться на предыдущую версию при необходимости.
Разумеется, поддержка совместимости на таком уровне дается весьма непросто. Это существенное вложение усилий в разработку, это существенная нагрузка на тестирование. Но мы считаем, что это окупается.
Один из подходов к развитию, используемых нами, во время обсуждений мы сравниваем с перестановкой шкафа. Вы когда-нибудь пробовали дома в одиночку переставлять большой шкаф из одного угла комнаты в другой? Если пробовали, то, конечно, знаете, что есть несколько методик («паттернов»).
Например, можно подложить кусок картона и тащить. Можно купить специальные колесики, которые подставляются под края шкафа. А можно переставлять шкаф по частям. Поднимать один из краев, поворачивать на небольшой угол вокруг ножки другого края, потом то же самое с другой стороны, и так далее.
Такой же подход можно применять и при развитии бизнес-приложений. В данном случае мы говорим и про платформу, и про сами приложения. Менять на определенном этапе некоторый аспект, но не трогать другие аспекты. Это позволяет не «обрушивать» на пользователей и специалистов изменения сразу по всем фронтам. И, соответственно, позволяет удержаться на тонкой грани допустимости изменений.
А еще необходимость поддерживать требуемую скорость развития приводит к достаточно сложному процессу планирования и разработки. Например, разработка платформы у нас сейчас ведется одновременно по пяти горизонтам планирования.
В версии, которые мы выпускаем в течение 2–4 недель, а при необходимости, в течение 1–2 дней, мы вносим тщательно отобранный набор исправлений критичных ошибок. В версии, выпускаемые с интервалом в 3–4 месяца, мы включаем небольшие, наиболее критичные доработки функциональности и широкий спектр исправлений ошибок. В третьем горизонте мы вносим существенное количество функциональных изменений. Ну и существуют еще два горизонта. С ростом уровня горизонта увеличивается масштаб изменений.
Если в заключение попытаться ответить на вопрос «И как же лучше?», то мы все-таки считаем, что развитие должно быть быстрым, и оно должно сопровождаться всевозможными мерами, обеспечивающими приемлемость этого быстрого процесса для пользователей.
Есть много такого, что будет нужно завтра, а готовить это нужно было еще вчера. Мы видим, что кроме всего того, что мы активно развиваем, есть еще немало аспектов, которые нужно бы развивать быстрее. И в любом случае нам приходится выбирать, какие аспекты системы развивать на текущем этапе с наибольшим приоритетом. Но выбор приоритетов – это уже другая тема.
С. Нуралиев
