Рассказываем, в чем суть закономерности, как она себя проявляет и что бывает, когда эту закономерность не учитывают в процессе проектирования и разработки IT-систем.
Фото — Spencer — Unsplash
В книге «Сам себе MBA. Самообразование на 100%», написанной Джошом Кауфманом (Josh Kaufman), закон Галла приведен в следующей формулировке:
Это означает, что к разработке любого проекта следует применять системный подход — двигаться от простого к сложному. Иными словами, нужно начинать с создания простых систем и постепенно двигаться в сторону их усложнения, расширяя функциональность и возможности.
Под простой системой обычно понимают систему, состоящую из небольшого числа элементов и не имеющую иерархии. Сложная система, наоборот, имеет разветвленную структуру и большое количество взаимосвязанных компонентов.
Автор закона Джон Галл (John Gall) по профессии был педиатром, но в свободное время занимался исследованиями в области теории систем. В 1977 году он опубликовал книгу «Систематизация: как работают системы и как они терпят крах». В ней он рассказывал, что для управления любой системой необходимо понимать, как факторы среды влияют на ее функциональность. Именно в этой книге и был сформулирован закон Галла.
Свою известность закон обрел благодаря упоминанию в книге «Структурированное техническое задание», написанной системным разработчиком Кеном Орром (Ken Orr) в 1981 году. Его работа обрела широкую популярность, и на неё до сих пор ссылаются авторы современной литературы по системному анализу.
Спустя какое-то время после публикации книги Кена Орра, правилом Галла «вооружился» Гради Буч (Grady Booch), когда создавал UML. В этом языке также прослеживается концепция «от простого — к сложному»: для построения абстрактной модели системы используют отдельные классы, типы и интерфейсы.
Фото — Isaac Smith — Unsplash
Также закон нашел отражение в гибких подходах к разработке ПО. В частности, правило применяется в экстремальном программировании (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 год — система не оправдала надежды разработчиков и пользователей и проект свернули.
Мы в ITGLOBAL.COM предоставляем частное и гибридное облако и предлагаем услуги, направленные на развитие IT-инфраструктуры клиентов. Надеемся, что этот материал показался вам полезным. Что можно почитать о нас, и о чем мы пишем сами в корпоративном блоге:
Фото — Spencer — Unsplash
В книге «Сам себе MBA. Самообразование на 100%», написанной Джошом Кауфманом (Josh Kaufman), закон Галла приведен в следующей формулировке:
«Любая работающая сложная система развивается на базе работающей простой системы. Сложные системы, созданные с нуля, никогда не будут работать в реальном мире, поскольку в процессе разработки на них не влияли факторы отбора, присущие среде».
Это означает, что к разработке любого проекта следует применять системный подход — двигаться от простого к сложному. Иными словами, нужно начинать с создания простых систем и постепенно двигаться в сторону их усложнения, расширяя функциональность и возможности.
Под простой системой обычно понимают систему, состоящую из небольшого числа элементов и не имеющую иерархии. Сложная система, наоборот, имеет разветвленную структуру и большое количество взаимосвязанных компонентов.
Минутка истории
Автор закона Джон Галл (John Gall) по профессии был педиатром, но в свободное время занимался исследованиями в области теории систем. В 1977 году он опубликовал книгу «Систематизация: как работают системы и как они терпят крах». В ней он рассказывал, что для управления любой системой необходимо понимать, как факторы среды влияют на ее функциональность. Именно в этой книге и был сформулирован закон Галла.
Свою известность закон обрел благодаря упоминанию в книге «Структурированное техническое задание», написанной системным разработчиком Кеном Орром (Ken Orr) в 1981 году. Его работа обрела широкую популярность, и на неё до сих пор ссылаются авторы современной литературы по системному анализу.
Спустя какое-то время после публикации книги Кена Орра, правилом Галла «вооружился» Гради Буч (Grady Booch), когда создавал UML. В этом языке также прослеживается концепция «от простого — к сложному»: для построения абстрактной модели системы используют отдельные классы, типы и интерфейсы.
Фото — Isaac Smith — Unsplash
Также закон нашел отражение в гибких подходах к разработке ПО. В частности, правило применяется в экстремальном программировании (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 год — система не оправдала надежды разработчиков и пользователей и проект свернули.
Чтение по теме:
- Джош Кауфман объясняет закон Галла
- Закон Галла в применении к стартапам
- Основные концепции системного подхода
- Книга: «Компьютерные сети: системный подход» на GitHub
Мы в ITGLOBAL.COM предоставляем частное и гибридное облако и предлагаем услуги, направленные на развитие IT-инфраструктуры клиентов. Надеемся, что этот материал показался вам полезным. Что можно почитать о нас, и о чем мы пишем сами в корпоративном блоге:
- Виталий Грицай: о стратегии международного развития ITGLOBAL.COM
- Зачем клиенту облачного провайдера знать об уровне надежности ЦОД
- Как бизнесу защититься от троянов-вымогателей
- ITGLOBAL.COM стала первым официальным реселлером Alibaba cloud в России
- ITGLOBAL.COM запустила корпоративную облачную площадку в Республике Беларусь
