Что делать теперь? Планирование при изменении проектных решений

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

Я понимаю чувство разочарования, которое возникает в подобной ситуации, однако это нечто, с чем нам в IT приходится сталкиваться весьма регулярно, и конструктивное управление этой реакцией является ключевым IT-навыком. Мы должны стать мастерами в этой ситуации как технически, так и эмоционально. Она не должна нас парализовать — это естественная ситуация, с которой каждый IT-специалист сталкивается постоянно. Она не должна обескураживать или лишать сил, хотя вполне понятно, что именно так она и воспринимается.

Одна из ключевых причин, по которой мы так часто оказываемся в подобной ситуации, заключается в том, что IT — это огромная область с большим количеством переменных, которые необходимо учитывать в каждом конкретном случае. Это также высокотворческая область, где существует множество жизнеспособных подходов к любой задаче. Наличие единственного «наилучшего» варианта — большая редкость. Обычно есть множество конкурирующих решений. Иногда они очень похожи между собой, иногда кардинально различаются, что делает их сравнение крайне затруднительным.

Ещё одна ключевая причина — то, что факторы меняются. Могут появиться новые методы или информация, выйти новые продукты, обновиться существующие, измениться цены или потребности бизнеса — причём в процессе принятия решений и проектирования или даже вовремя него. Этот темп изменений — то, что мы как IT-специалисты не можем надеяться когда-либо контролировать. Это то, что мы должны принять и по возможности с этим справляться.

Ещё одна вещь, которую я часто вижу упускаемой из виду: решение, которое было оптимальным в момент принятия, может оказаться неоптимальным, если бы то же решение принималось сегодня. Это никоим образом не означает недостатка исходного проекта, однако я видел, как многие люди реагируют на это именно так. Наиболее распространённый сценарий, при котором я наблюдаю подобное поведение, — нежелание использовать RAID 5 в современных системах хранения данных; RAID 6 и RAID 10 являются популярными альтернативами на то есть веские причины. Но это неприятие RAID 5, распространившееся примерно с 2009 года, существовало не всегда: с середины 1990-х до конца 2000-х RAID 5 не только был жизнеспособным, но и нередко был лучшим решением для конкретных бизнес- и технических нужд (нарастание неприятия было в основном постепенным, а не внезапным). Тем не менее многие люди справедливо считают RAID 5 плохим вариантом сегодня, но переносят это отношение на системы, спроектированные и внедрённые давно — иногда почти два десятилетия назад. Это лишено логики и является исключительно эмоциональной реакцией. То, что RAID 5 был лучшим выбором для конкретного сценария в 2002 году, никоим образом не означает, что он останется лучшим выбором в 2015 году. Но точно так же то, что RAID 5 является плохим выбором в 2015 году, никоим образом не умаляет тот факт, что несколько лет назад он нередко был отличным решением.

Меня много раз спрашивали, что делать, когда уже были приняты не самые оптимальные проектные решения. «Что мне теперь делать?»

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

Принятие того факта, что ни один проект не является совершенным, что невозможно всегда всё сделать правильно и что работа с этим — просто часть работы в IT, является первым шагом. Сделайте шаг назад, глубоко вздохните. Всё не так страшно. Это не уникальная ситуация. Каждый IT-специалист, занимающийся проектированием, постоянно через это проходит. Вы должны стараться принимать наилучшие возможные решения, но также должны принять, что это редко удаётся в полной мере — ни у кого нет доступа к достаточному количеству ресурсов для того, чтобы действительно это сделать. Мы работаем с тем, что имеем. Итак, мы здесь. Что дальше?

Следующий шаг — оценить ситуацию. Где мы находимся сейчас? Во многих случаях реализация завершена и ничего больше не остаётся сделать. Ситуация не идеальна, но насколько она плоха? Очень часто самая большая ошибка, которую я вижу у людей, столкнувшихся с уже реализованным проектом, состоит в том, что он слишком дорог. Как правило, «лучшие» решения являются таковыми не потому, что они быстрее или надёжнее, а потому что они дешевле, проще или быстрее в реализации. Это неприятная ситуация, но отнюдь не критическая. Всё затраченное время или деньги должны были быть приемлемыми на тот момент и должны были быть одобрены. Всё, что мы можем сделать прямо сейчас, — это извлечь уроки из процесса принятия решений и постараться избежать перерасхода в будущем. Это не означает, что существующее решение не будет работать или даже не будет работать превосходно. Просто, возможно, оно не было идеальным выбором с учётом бизнес-потребностей, прежде всего финансовых.

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

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

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

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

Точно так же мы должны вести себя в IT. Наше текущее состояние — это наше текущее состояние. Для стратегического планирования не имеет значения, что привело нас к этому состоянию. Мы думаем об этих решениях и затратах только при проведении анализа после завершения проекта, чтобы определить, где мог дать сбой процесс принятия решений и извлечь из этого уроки. Изучение себя и своих процессов очень важно. Но это совершенно иная задача, нежели стратегическое планирование для текущей инициативы.

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

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

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

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