Tuesday, June 2, 2009

Гибкость и сложность

Где начало того конца, которым оканчивается начало?
Козьма Прутков. Мысли и афоризмы.


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

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

Прежде всего давайте поймем, почему же мы вожделеем гибкость.
1. На момент выбора решения не известно что конкретно хочется. Действительно, аппетит появляется во время еды. Да, я знаю, что во всех книжках написано, что подход такой неправильный и что надо на момент выбора решения знать все, что хочется, но на практике, к сожалению, это так.
2. В России очень трудно прогнозировать. На практике все меняется самым непредполагаемым образом: вчера мы поклонялись коммунистам и были пионерами, сейчас узнали, что коммунисты были нехорошие люди, так как уничтожили духовность.... Как следствие, приходится закладываться на все "случаи жизни" - вместо восседания на одной бочке с порохом, сидеть на двух, а может, и больше, чтобы, в случае взрыва одной, успеть перескочить на следующую.

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

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

4 comments:

Igor Gots said...

Мне кажется автор ограничил количество рассматриваемых факторов выбора. Ведь на самом деле приобретая "техрешение", мы покупаем не буханку хлеба, которую со временем съедим, а систему, которая будет существовать в постоянно изменяющемся окружении. Так или иначе, требования к ней определяются средой, в первую очередь, потом толщиной кошелька и лишь потом функциональностью. Но учитывая узость рынка ИБ, зачастую уже после выполнения первого набора требований (среда) выбора практически не остается.
Теперь о пилотном внедрении. Это красиво в теории, а реально это приводит к удорожанию проекта, при чем ситуация такова, что сотрудники участвующие в пилоте ничего кроме дополнительной головной боли не получают.
Отсюда мой вариант: четкое описание необходимого функционала, возможно общение с коллегами и знакомство с реализованными проектами, стендирование решения силами заинтересованного подразделения, с последующей тестовой эксплуатацией и внедрением.

Sergey Soldatov said...

"... стендирование решения силами заинтересованного подразделения, с последующей тестовой эксплуатацией и внедрением"

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

Igor Gots said...

Из моего опыта работы у интеграторов, опытное внедрение, это работа на 5-10% живого материала. Опыт у нас разный :)

Amiran Alavidze said...

Клип в тему:
http://www.youtube.com/watch?v=R2a8TRSgzZY