В этой статье я обобщила типичные случаи, когда перепроектирование является свидетельством развития приложения или всей отрасли, а когда оно вызвано ошибками первичного проектирования и разработки, а также те выделила те случаи, когда перепроектирования можно избежать.
Меня зовут Ерохова Елена и я аналитик.
В моей практике перепроектирование встречалось почти так же часто, как проектирование с нуля.
Неоднократно приходилось перепроектировать как готовые, работающие приложения, так и приложения, застрявшие в процессе разработки, которые еще даже не начали работать.
Перепроектировать – значит изменять устройство и функции приложения с целью получения новых результатов его работы, изменять проект, а затем и реализацию программного продукта.
Здесь я имею в виду, что «проект» - записанные в документ образ результата прикладного программирования и последовательность этапов по достижению этого результата.
При перепроектировании необходимо создавать новый образ результата и новый план его достижения.
Перепроектирование – это, практически, всегда сложно, затратно и неприятно.
Может быть, можно с самого начала так спроектировать приложение, чтобы потом не перепроектировать его?
Причины перепроектирования
Полностью избежать перепроектирования приложений невозможно потому, что, в части случаев, перепроектирование свидетельствует о развитии приложения или отрасли, а не об ошибках, допущенных при его проектировании и разработке.
Почему люди перепроектируют приложения?
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. Важно не просто составить списки стейкхолдеров и результатов, но сопоставить их иерархии, чтобы составить верное представлении о приоритетах в приложении и не упустить ничего действительно важного, приоритетного для работы приложения.
Иерархиям стейкхолдеров и результатов работы приложения, а также приоритизации я планирую посвятить следующие свои публикации.
Не переключайтесь!
