Что означает закон Галла и почему его важно учитывать при создании IT-проектов?
Закон назван в честь теоретика в области систем Джона Галла и звучит так:
«Любая работающая сложная система развивается на базе работающей простой системы. Сложные системы, созданные с нуля, никогда не будут работать в реальном мире, поскольку в процессе разработки на них не влияли факторы отбора, присущие среде».
Другими словами, при создании проекта нужно двигаться от простого к сложному. Начинать с разработки простых систем и постепенно их усложнять, добавляя функционал.
Под простой подразумевают такую систему, которая состоит из небольшого числа элементов и не имеет иерархии. Сложная система имеет разветвленную структуру и большое количество взаимосвязанных компонентов.
Минутка истории
Автор закона Джон Галл (John Gall) по профессии был педиатром, но в свободное время занимался исследованиями в области теории систем. В 1977 году он опубликовал книгу «Систематизация: как работают системы и как они терпят крах». В ней он рассказывал, что для управления любой системой необходимо понимать, как факторы среды влияют на ее функциональность. Именно в этой книге и был сформулирован закон Галла.
Свою известность закон обрел благодаря упоминанию в книге «Структурированное техническое задание», написанной системным разработчиком Кеном Орром (Ken Orr) в 1981 году. Его работа обрела широкую популярность, и на неё до сих пор ссылаются авторы современной литературы по системному анализу.
Спустя какое-то время после публикации книги Кена Орра, правилом Галла «вооружился» Гради Буч (Grady Booch), когда создавал UML. В этом языке также прослеживается концепция «от простого — к сложному»: для построения абстрактной модели системы используют отдельные классы, типы и интерфейсы.
Также закон нашел отражение в гибких подходах к разработке ПО. В частности, правило применяется в экстремальном программировании (XP). Одна из основных концепций этой методологии — простота проектирования. Она гласит, что новый продукт не следует проектировать заблаговременно и целиком. Планирование должно выполняться итерационно, с учётом постоянно изменяющихся требований (заказчика и рынка).
Когда следовать закону Галла
Наиболее ярким примером для иллюстрации закона Галла служит World Wide Web. Она зародилась как локальный проект CERN — организация разрабатывала инструмент для связывания документов посредством гипертекстовых ссылок. Но со временем сеть успешно разрослась до мировых масштабов — её возможности расширялись, структура усложнялась и «обрастала» новыми протоколами (например, HTTPS, который стал развитием HTTP).
Старт разработки с MVP (minimum viable product) дает возможность оперативно протестировать идею и при необходимости изменить функциональность. Например, первая версия сервиса Uber содержала только две простые функции: вызов водителя и оплата поездки банковской картой. С их помощью команда проверила свою концепцию, привлекла пользовательскую базу и продолжила развивать продукт. Сегодня эти базовые функции усложнились: появилась возможность разделить счет между несколькими людьми, отслеживать водителей на карте и проводить автоплатежи.
Закон Галла помогает сделать UI понятнее для пользователей. Например, первая версия приложения Dropbox имела очень простой интерфейс — он представлял собой обыкновенную файловую папку. По словам разработчиков, именно эта особенность позволила привлечь большое количество новых пользователей — за несколько дней список заявок на бета-тестирование Dropbox пополнился на 70 тыс. Дополнительные функции и диалоговые окна — вроде совместного редактирования файлов — начали появляться позже.
Что бывает, когда эту закономерность не учитывают
Как пример проекта, при создании которого разработчикам стоило знать про закон Галла и учитывать его, обычно приводят технологический стандарт CORBA. Его спецификация изначально была объемной и содержала большое количество инструкций. Из-за излишней сложности разработка стандарта велась долгое время, при этом многие из его возможностей так и не были реализованы на практике. В итоге CORBA не получил широкого распространения.
В качестве примера неудачной реализации программного продукта можно привести Digital Media Initiative (DMI) — проект BBC от 2008 года. Его целью было создание масштабной платформы с in-house инструментами для монтажа видео и хранения контента. В основу DMI сразу заложили большое количество спецификаций, реализовать которые на практике не получилось. Разработка тянулась пять лет, но так и не была завершена. Сначала от проекта отказался исполнитель — компания Siemens — а затем и сама BBC. Всего на DMI потратили 100 млн фунтов.
Примером неудачной реализации интерфейса может служить сервис Google Wave. Он должен был объединить функциональность онлайн-форумов, социальных сетей, мессенджеров и систем управления версиями. Создатели платформы предполагали, что она станет универсальным способом общения. Но в попытке заменить «всё и сразу» команда разработчиков перегрузила приложение разными функциями. В результате пользователям приходилось долго разбираться с особенностями интерфейса. Сложности возникали даже с поисковой строкой сервиса — для работы с ней нужно было знать специальные теги. Проект развивали с 2009 по 2010 год — система не оправдала надежды разработчиков и пользователей и проект свернули.