Comments 4
За время работы с программными продуктами в различных сферах бизнеса мне не раз приходилось участвовать в принятии решений о том, какой функционал нужно выпустить в первую очередь и как он должен выглядеть.
Удалось ли вынести из всего этого опыта какую-либо теорию создания прикладных систем? На первый взгляд, кажется что "какой функционал нужно выпустить в первую очередь и как он должен выглядеть" определяется прежде всего самой задачей, некоторым выбранным порядком её решения. Можно было бы ожидать, что в результате накопленного многолетнего опыта, можно определить правильный порядок решения практически любой прикладной задачи. Теория суть обобщение опыта.
Мы использовали совершенно разные подходы для решения такой задачи, начиная с мнения разработчиков и заканчивая анализом поведения пользователей и его влияния на прибыль компании.
По идее, разработчики должны опираться на имеющуюся теорию (если она есть), и сами задавать правила игры.
Накопление опыта должно, видимо, сопровождаться накоплением библиотек компонентов. И, вообще, возрастанием понимания роли компонентов. При решении различных задач всегда есть определённые общие элементы. Вот эти общие элементы и есть компоненты. Например, наличие пользователей потребует реализации компонента Пользователи. На более низких уровнях реализации встречаются другие компоненты. Взаимосвязь компонентов составляет архитектуру приложения (определённого класса). Вот и кажется, что получение опыта должно быть сопряжено с формированием библиотеки компонентов и формированием архитектуры. Тогда и результат пройденного пути можно будет излагать в виде "мы разработали...", "мы предложили...".
Эффективность разработки можно оценить ещё и по тому, что мы обнаруживаем в самом конце разработки:
Только заканчивая работу мы начинаем понимать, с чего её надо было начинать.
Всегда хочется спросить, что мы должны были знать и уметь в самом начале, чтобы сразу придти к конечному результату. Вот этот сухой остаток и есть то, что мы должны запомнить и обобщить. Можно ли было пройти прямо? Да, можно было. Но для этого надо было долго думать, а уже потом делать. (Семь раз отмерь...) Довольно трудно действовать, когда конечная архитектура неизвестна.
Подход, основанный на экспериментировании, конечно, представляется любопытным. Но здесь не хватает последнего шага. А именно: понимания того, что система на этапе разработки это ещё не конечная система. Система на этапе разработки — это имитационная модель. Попробуйте просто поставить всем сотрудникам компании сетевой мессенджер с обязательством вести все дела через этот мессенджер. Обеспечте пользователей средствами описания сущностей, операций над сущностями и представлением о номенклатуре решаемых в данной организации прикладных задач. Вы довольно быстро получите рабочий макет системы и набор репрезентативных экспериментальных данных. И только потом, когда возникнет точное соответствие между деятельностью и её визуальным и алгоритмическим обеспечением (типичный градиентный спуск в многомерном параметрическом пространстве!), можно будет сделать релиз системы без лишних элементов, "фич" и других плохо документированных возможностей. (Не понимаю, почему так никто не делает? Хотя, кажется, что так должны действовать все.)
Попробуйте просто поставить всем сотрудникам компании сетевой мессенджер с обязательством вести все дела через этот мессенджер.
Мне кажется Microsoft Teams развивается каким-то таким путем и это уже который год самый ужасный мессенджер.
Попробуйте просто поставить всем сотрудникам компании сетевой мессенджер с обязательством вести все дела через этот мессенджер.
Результатом будут огромные неструктурированные кучи сообщений, при работе с которыми даже поиск не помогает. И это уже при 3-4 человеках в чате!
Обеспечте пользователей средствами описания сущностей, операций над сущностями и представлением о номенклатуре решаемых в данной организации прикладных задач. Вы довольно быстро получите рабочий макет системы и набор репрезентативных экспериментальных данных.
То есть разработкой системы будут заниматься пользователи? Или пользователи станут программистами? Рядовой пользователь не очень умеет в "описания сущностей", "описания операций над сущностями". Для получения этих описаний нужны как знания прикладной области, так и знания ИТ.
Система на этапе разработки — это имитационная модель.
И только потом, когда возникнет точное соответствие между деятельностью и её визуальным и алгоритмическим обеспечением (типичный градиентный спуск в многомерном параметрическом пространстве!), можно будет сделать релиз системы без лишних элементов, "фич" и других плохо документированных возможностей. (Не понимаю, почему так никто не делает? Хотя, кажется, что так должны действовать все.)
А примерно так и делают, только артефакты "имитационной моделью" никто не называет. Гибкие методологии разработки (например, скрам) сначала выпускают минимальный продукт (это сразу продукт, не имитационная модель), а затем итеративно улучшают его. Конечного вида системы может и не быть - пока система жива и используется, появляются новые идеи, и система куда-то эволюционирует. Градиентный спуск с целью максимизации прибыли, да.
Эксперименты. Или как понять, удачная ли была фича?