IT ManagerИТ в бизнесеЧто хочет бизнес

Колосс на глиняных ногах

Дмитрий Мартынов | 26.11.2015

ВКонтакт Facebook Google Plus Одноклассники Twitter Livejournal Liveinternet Mail.Ru

Колосс на глиняных ногах

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

Предложу простое, но противоречивое толкование. Концепция – это предельно краткое описание системы, содержащее большое количество полезных для дела деталей. Где подвох? Как в краткое описание может поместиться куча деталей? Не знаю, хорошая концепция – это искусство. Не зря же говорят: «красивая концепция» или, наоборот, «путаная концепция». Именно возможность кратко передать сложные вещи и воспринимается (ощущается) специалистами как красота…

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

Где раки зимуют

Основная проблема большинства проектов разработки программного обеспечения связана с «уплыванием» требований от первоначальных. Объяснений существует несколько:

  1. Мы живем в очень динамичном мире. В любом деле инструменты быстро меняются. Вслед за этими изменениями нужно менять и программы.
  2. Хорошая программа – это совершенно новый инструмент в руках специалиста, и ее использование меняет процесс работы. Изменения, конечно, планируют заранее, но не все удается предсказать. Инструмент новый, и многое используется не так, как ожидалось. Какие-то изначально задуманные функции оказываются лишними, ну и ладно. Но ведь других нужных функций в ПО теперь не хватает.
  3. Как только специалист берет программу в свои руки, он ощущает невероятные возможности, тут же появляются неожиданные требования по усовершенствованию для получения дополнительных полезных эффектов.

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

Итого: как бы вы ни старались, наверняка придется переписывать техническое задание и саму программу. Но если старания напрасны, надо ли стараться?

Возьмем для примера процесс планирования. Планирования чего? Да всего. Если мы знаем, что план наверняка будет нарушен, все равно надо планировать. И чем более внимательно мы отнесемся к этому процессу, тем реже будет нарушаться план и тем лучше будет результат. Так и с проектированием системы: надо стараться выполнить его так, чтобы минимизировать риски переписывания и одновременно сделать систему удобной для переделки. Это два ключевых подхода, о которых мы и поговорим. И начнем с программы, которая должна быть ремонтопригодной.

Конструктор-самоделкин

Как это делается обычно

Детали программного обеспечения тщательно прописываются в ТЗ. Описывают даже в подробностях, кто какую кнопку и в какой момент будет нажимать. Разрабатывая программу по такому ТЗ, программист строит готовое решение, менять которое не предполагается. Главный принцип упущен…

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

Как надо

Хорошая архитектура системы позволяет не переписывать ее каждый раз, а вносить небольшие изменения. Главное отличие здесь в том, что надо создавать не продукт, а конструктор, из которого будет собираться будущее решение. Потратив много времени на конструктор и чуток на внешний интерфейс, можно считать решение готовым по сути. Даже если потребуется развитие, можно быстро смонтировать нужные части и отштукатурить фасад.

Нередко на презентации решения можно услышать такой диалог:

– А как в вашей программе можно сделать вот это?

– Это можно сделать тремя разными способами.

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

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

Издержки и главный вопрос (а может быть, не главный?)

Из предложенного подхода вытекают неожиданные трудности: когда нужно представить промежуточные результаты своей работы (отчет о том, как идет процесс разработки), показать-то нечего, так как конструктор – это процедуры и функции, суть работы которых контроллеру объяснить не так уж и просто.

Как быть? Ответ: не мешать все в кучу. Нам нужен результат, а не мониторинг. Контроль инновационного процесса одновременно несет пользу (улучшает планирование, мотивирует к своевременному выполнению работ) и негатив (стресс для контролируемого и отвлечение его от основной работы). Что перевешивает? Никаких обстоятельных исследований на эту тему не приходилось видеть. Лично я уверен (писал об этом в статье «Купля-продажа жемчуга, или Разговор о неделимых операциях», IT-Manager № 4 ‘2013 год), что промежуточный результат инновационного проекта с точки зрения контроля – это всегда бутафорская презентация, в которой контроллер избавлен от сложных и непонятных ему деталей. То есть польза отсутствует, а негатив остается.

Поэтому оставим тему контроля на следующий раз и поговорим о главном: как сделать удобный конструктор? С чего начать и как закончить? То есть, как и было обещано, переходим ко второму ключевому вопросу – архитектуре.

Опоры

Чтобы минимизировать переписывание программы (избежать этого полностью нельзя, но сократить объем работ можно), нам нужна хорошая архитектура. Что означает это заезженное слово «хорошая», мы сейчас увидим.

Проблема

Процесс создания конструктора буду объяснять на примере проектирования систем для бизнеса. Итак, все программы учета и управления принято проектировать от процесса, который состоит из: сотрудников, отделов, должностей, обязанностей, процессов, результатов, отчетов о результатах и т. д. Именно этот компот и порождает хаос в условиях постоянной перетряски, которая происходит всегда. Проект разработки и внедрения ПО длится определенное время, и если задачи поставлены в терминах отделов, сотрудников и обязанностей, то уже к середине проекта выясняется, что всего этого уже нет. Сотрудники сменились, отделы реорганизовали, обязанности перераспределили.

Раз здесь трясина, то где же твердая почва? Как известно, глаз реагирует прежде всего на движение, поэтому неподвижного слона легко и не заметить. Посмотрите внимательно: ведь стабильность – она везде вокруг нас.

Решение

В каждом бизнесе есть какие-то незыблемые сущности. Это те операции (или их части), мероприятия, физические объекты, которые наверняка останутся неизменными в течение десятков лет. Именно на них и надо опереться при проектировании архитектуры.

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

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

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

На века

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

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

Журнал IT-Manager № 11/2015    [ PDF ]    [ Подписка на журнал ]

Об авторах

Дмитрий Мартынов

Дмитрий Мартынов

Эксперт компании Koder Logic (www.koderlogic.ru), управляющий партнер Интеллектуальной группы «Киборг» (www.kiborg.net), известен как идеолог «честности в управлении» и как автор термина «Indulgence Management». Его исследования цитируются в научных работах и используются в качестве учебных материалов в ВУЗах. Ведет авторские курсы по проблемам внедрения ИТ систем на предприятиях, по эффективным практикам эксплуатации ERP и CRM систем и по принципам защиты компаний от воровства и коррупции.

Мероприятия

23.09.2018 — 25.09.2018
XII Конгресс "Подмосковные вечера"

Москва, Атлас Парк Отель. Домодедово, Судаково, 92,

26.09.2018
Loginom Day 2018: продвинутая аналитика, легкая в приготовлении

Москва, event-холл «Инфопространство»

02.10.2018 — 03.10.2018
Открытая конференция для бизнеса и ИТ «ACCELERATE»

Москва, Краснопресненская набережная, 14 Экспоцентр

02.10.2018
Практики построения современного трейдинга

Москва, Арарат Парк Хаятт, зал Саргсян

04.10.2018 — 05.10.2018
БИТ Санкт-Петербург 2018

Санкт-Петербург, проспект Медиков, дом 3, Конгресс-центр «ЛПМ»