Юрген Аппело - Agile-менеджмент. Лидерство и управление командами

Да, я знаю, что это звучит по-дурацки. Но мир в целом иногда выглядит по-дурацки.

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

Успех – это длительное отсутствие неудач. С моей точки зрения, продукт может представлять ценность, даже если процесс его разработки не уложился в график и вышел за пределы бюджета; даже если имеет место неудовлетворительный возврат инвестиций и даже если не все заинтересованные стороны довольны. Биологические виды успешны, пока не вымрут. Мой автомобиль успешен до тех пор, пока он мне не разонравится. Программные продукты успешны, пока не потеряют всех своих пользователей. Принципы принятия изменений и непрерывного улучшения направлены на то, чтобы отложить неизбежный момент потери последнего пользователя. Рано или поздно все программные продукты постигает неудача. Я на 99,9 % в этом уверен.

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

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

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

На протяжении нескольких страниц я пытался показать, что неопределенность будет всегда и что необходимо адаптироваться к изменениям. Не исключено, что вам все это надоело до слез и вас клонит в сон. Попробуем разбудить вас и обсудить практические аспекты неопределенности. Как вести себя в среде, характеризующейся неопределенностью? Как управлять непрерывными изменениями? Увы, универсального рецепта не существует. Управление изменениями в значительной степени будет ситуационным и зависит как от операционной среды, так и от характеристик самой организации [Bennett 2004: 10].

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

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

Сложные проблемы обычно связаны с непредсказуемостью. Они не просто непредсказуемы – невозможно предсказать, в чем именно проявится их непредсказуемость [92].

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

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