Подбираем решение или вопросы, на которые должны быть ответы

Категория: Фундаментальные статьи

– Автор: Игорь (Администратор)

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

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

Частично об этом уже шла речь в обзоре Универсальное или уникальное решение. Что лучше?. Однако существуют некоторые моменты, которые имеет смысл более подробно описать.

Есть ли экспорт/импорт данных и настроек?

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

Безусловно, если объем данных и настроек настолько мал, что легко переносится в течение 10-20 минут ручным копированием, то этот вопрос вы, скорее всего, проигнорируете. Но, все же, этим вопросом стоит задаться. Если сегодня система никак не связана с другими решениями на вашем компьютере или в вашей сети, то в будущем ситуация может поменяться. Представьте, что вам придется ежедневно тратить по 10-20 минут на ручной перенос данных из одной системы в другую. Рано или поздно вы задумаетесь над вопросом "а есть ли решение с экспортом и импортом?".

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

Кстати, вот еще интересный обзор Автоматизация рутинных задач - польза и вред.

Как решается вопрос расширения функциональности?

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

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

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

Какой запас прочности относительно текущих потребностей?

Вопрос запаса прочности это не только вопрос о поддерживаемом объеме данных и о ресурсопотреблении, это еще и вопрос о запасе функциональности и возможностей для ее расширения. Если с объемами данных и ресурсопотреблении все достаточно просто - "что будет через год-два, когда данных станет на порядок больше" и прочие аналогичные вопросы. То с запасом функциональности и возможности расширения ситуация обстоит несколько сложнее. Далеко не всегда можно заранее предугадать какие задачи понадобится решать в последующем. Безусловно, обычно существует набор функций, которые, с большой долей вероятности, могут пригодится. Однако не существует 100% гарантии, что это обязательно случится.

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

К примеру, если вы используете бесплатный программный продукт, который поддерживается достаточно большим сообществом, то обычно это означает, что у данного продукта уже есть достаточно большая база дополнительных расширений "на все случаи жизни". Например, как у WordPress, Joomla, OpenCart и прочих. Кроме того, за то время, пока вы не нуждаетесь в определенной функциональности, существует вероятность, что такая функциональность появится в базе расширений.

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

Какие существуют решения с аналогичной или похожей логикой?

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

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

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

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

Понравилась заметка? Тогда время подписываться в социальных сетях и делать репосты!

• Достоинства и недостатки: почему найти их можно только в обзорах и аналитиках?
• Статические или динамические методы построения сайтов (ajax)?