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

Меня зовут Ерохова Елена и я аналитик.

В моей практике перепроектирование встречалось почти так же часто, как проектирование с нуля.

Неоднократно приходилось перепроектировать как готовые, работающие приложения, так и приложения, застрявшие в процессе разработки, которые еще даже не начали работать.

Перепроектировать – значит изменять устройство и функции приложения с целью получения новых результатов его работы, изменять проект, а затем и реализацию программного продукта.

Здесь я имею в виду, что «проект» - записанные в документ образ результата прикладного программирования и последовательность этапов по достижению этого результата.

При перепроектировании необходимо создавать новый образ результата и новый план его достижения.

Перепроектирование – это, практически, всегда сложно, затратно и неприятно.

Может быть, можно с самого начала так спроектировать приложение, чтобы потом не перепроектировать его?

Причины перепроектирования

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

Почему люди перепроектируют приложения?

1.    Перепроектирование может быть следствием развития самого приложения.

Пример: вы выпустили маленькую внутрикорпоративную социальную сеть, которой пользовались 1 000 человек, и она хорошо справлялась с нагрузками.

Разработка оказалась настолько удачной, что вы стали использовать эту же сеть для взаимодействия с 10 000 ваших клиентов. И приложение не смогло справиться с нагрузками, а значит, его нужно перепроектировать.

Это пример перепроектирования, связанного с развитием приложения, вызвавшем увеличением нагрузок, а не с ошибкой и разработки или проектирование.

2.    Перепроектирование может быть следствием развития всей отрасли IT.

Пример: вы 10 лет успешно вели учет маркетинга и продаж в своей индивидуально разработанной, удобной CRM-системе, но каждую неделю вы в течение 6 часов ждали формирования сводного отчета по сотням тысяч торговых операций.

Все было отлично. Ежедневная работа в системе удобна, но формирование большого сводного отчета приходилось ставить на ночь и, в случае необходимости переформирования этого отчета, ждать много часов.

За 10 лет, пока вы пользовались вашей CRM, не только вырос ваш бизнес, ваши объёмы операций. За это время появились новые технологии, с которыми вы можете повысить скорость обработки данных в разы. Например, сформировать отчет за 10 минут, а не за 6-8 часов. А для этого необходимо перенести логику приложения на новые технологии, а значит, перепроектировать его.

3.    Перепроектирование может быть связано и с развитием среды, в котором используются успешные приложения.

Пример 1: в стране законодатели ввели новый налог.

Например, когда ввели НДС, все бухгалтерские, складские, финансовые программы были существенно доработаны.

Пример 2: на рынке появились новые приборы или оборудование, которые могут быть подключены к приложению.

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

Для подключения сканера штрих-кодов к складским учетным программам недавно разработчики складских и бухгалтерских программ массово делали перепроектирование и доработки.

Пример 3: появились технологически новые каналы продаж через маркет-плейсы, магазины внутри соцсетей.

Всего 20 лет назад все торговали через оффлайн-магазины, затем вступили интернет-магазины, а теперь торгуют через соцсети и маркетплейсы. Приложения для учета ведения торговли однажды были состыкованы, интегрированы с соцсетями и маркетплейсами. То есть, перепроектированы, чтобы адаптироваться к новым каналам сбыта.

4.    Перепроектирование может быть связано и с опытом успешного использования приложения, когда из опыта была выявлена необходимость добавить новые функции.

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

Владельцы интернет-магазина заказали разработку рекомендательной системы.

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

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

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

Подведём итоги:

перепроектирование, вызванное развитием, а не ошибками встречается в случаях:

1)    успеха приложения и роста нагрузки на него;

2)    развития или изменения среды, в которой используется приложение и появление новых требований среды;

3)    развития всей IT-отрасли или конкретного стека технологий, появление новых технологических возможностей;

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

Все эти случаи перепроектирования нормальны, оптимистичны и их нельзя избежать.

Перепроектирование из-за ошибок

Совсем другое дело, когда перепроектировать приложение приходится из-за ошибок проектирования или разработки.

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

1.    Проектирование отчетов по остаточному принципу

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

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

При этом в процессе разработки упускаются функции и структуры данных, которые должны обеспечивать какой-то важный отчёт, график, дашборд, исходящий документ или другой результат работы приложения.

2.    Неучет статусных стейкхолдеров, которые не работаю напрямую в приложении

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

Это ситуация, когда приложение может давать важный результат какому-то вышестоящему лицу, которое даже не имеет логина-пароля в этом приложении, но является статусным получателем отчетов из приложения.

Например, совет директоров холдинга не имеет доступа к работе к ERP-системе подчиненного предприятия, но совет директоров должен регулярно получать из ERP-системы сводные отчёты.

Второй пример: ни один сотрудник правительства не имеет доступа и не работает с программным обеспечением какого-то министерства, но правительство должно регулярно получать отчёты из приложения, используемого этим министерством.

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

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

В этих примерах и совет директоров, и правительство – важные, статусные стейкхолдеры, заинтересованные стороны. С другой стороны, с точки зрения функций приложения, ни совет директоров, ни правительство не действуют в приложении, не имеют в него доступа, не вызывают никаких функций приложения, а значит, они не акторы.

Эти ошибки проектирования логичны, если мы считаем, что мы автоматизируем процессы. При таком фокусе внимания важных получателей результатов работы приложения, не имеющих своих бизнес-процессов, мы просто упускаем.

А если мы примем точку зрения, что мы автоматизируем не процессы, а что-то другое?

Мы автоматизируем получение результатов. При таком фокусе внимания мы не пропустим результаты статусных стейкхолдеров, не являющихся акторами.

3.    Проектирование ролевой модели по остаточному принципу.

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

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

И во всех трех приведенных мной случаях приложение не оправдывает возложенных на него надежд, не предоставляет пользователям и заказчикам тех ценностей, на которые они рассчитывали.

И приложение подлежит перепроектированию.

Что является критерием необходимости перепроектирования

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

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

Например, не дает нужный отчет (нет результата) или формирует отчет очень долго (результат есть, ограничения не учтены).

Или дает неверно сформированный отчет, некорректный.

То есть, если мы сразу правильно спроектировали приложение, то оно

1)    дает все необходимые результаты,

2)    эти результаты корректны и

3)    эти результаты учитывают требования среды.

Если проект приложения – это образ будущего результата плюс последовательность шагов по его достижению, то образ будущего приложения - описание суммы результатов работы приложения.

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

На пути от идеи до готового приложения необходимо сначала сформулировать границы приложения (что приложение делает, а чего оно точно не делает).

Это пресейловый, допродажный проект, в котором согласуется видение будущего продукта заказчиком и разработчиком.

А затем пресейловый проект должен быть преобразован в технический проект, техническое задание.

Вернемся к вопросу перепроектирование.

У перепроектируемого приложения в проекте перепроектирования есть 3 типа результатов:

1.    Существующие результаты, которые формируются корректно и их надо сохранить.

2.    Существующие результаты, которые формируются некорректно и их надо исправить.

3.    И отсутствующие результаты, которые нужно добавить.

Что является критерием хорошо разработанного приложения

Значит, чтобы с самого начала спроектировать приложение так, чтобы не перепроектировать его, нам нужно правильно описать образ будущего приложения как сумму его корректных результатов в условиях ограничений среды, в которых будет работать это приложение. И учесть интересы как тех стейкхолдеров, которые являются акторами в приложении, так и тех, которые сами в приложении не работают, но являются важными получателями результатов работы приложения.

Это является реальным критерием приёмки правильности работы приложения в глазах заказчика/пользователя.

Выводы:

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

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

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

4.    Важно не просто составить списки стейкхолдеров и результатов, но сопоставить их иерархии, чтобы составить верное представлении о приоритетах в приложении и не упустить ничего действительно важного, приоритетного для работы приложения.

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

Не переключайтесь!