среда, 12 января 2011 г.

М.Болтон: Оценка проекта и Черные Лебеди. Часть 4.

Вольный перевод статьи Майкла Болтона Project Estimation and Black Swans (Part 4)


В нескольких последних статьях исследовательская автоматизация подсказала некоторые интересные идеи насчет динамики проектов и их оценки. Какую пользу можно извлечь из этих математических экспериментов?

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

Похоже, математика поддерживает идеи, расхваливаемые энтузиастами Agile, гуманистами и мыслителями: получайте обратную связь быстро и часто. Глядя на последнюю модель - меньше задач и более короткие проекты - мы можем предположить, что чем короче и управляемей проект, тем меньше шансов у Черного Лебедя нанести вред любому отдельно взятому проекту.

Другая правдоподобная идея, порожденная математикой: избегайте проектов, к которым применим закон степенного распределения - проектов, где вы уязвимы перед Потраченными Утрами и Потерянными Днями. Не беритесь за проекты из четвертого квадранта Талеба, проекты, которые могут содержать слабо определенные задачи, обладающие большим влиянием. Работайте, насколько это возможно, с достаточно предсказуемыми вещами, чтобы статистика случайных и непредсказуемых событий не так уж часто наносила нам вред. Оставайтесь в области известного, "в Среднестане", как сказал бы Талеб. Правьте к следующему острову вместо попыток уплыть далеко за линию горизонта.

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

Кто-то может предложить нам устранить изменчивость, неизвестность и непредсказуемость. Какая отличная идея! По определению, неизвестность - это состояние незнания чего-либо; по определению, что-то непредсказуемое не может быть предсказано. Снежные бури случаются (даже в Британии!). Компьютеры ломаются. В Индии регулярно отключается электричество - когда я последний раз был в Индии, оно отключалось трижды во время занятий и еще трижды вечером за два дня пребывания в отеле бизнес-класса. В Северной Америке отключения электричества тоже случаются - и поскольку мы не привыкли к ним, мы не готовы действовать в такой ситуации. (Для нас это Черный Лебедь, хотя для живущих в Индии это - Серый Лебедь). Руководители назначают общие собрания, порой с печальными новостями. Сервера падают. Бэкапы портятся. Люди болеют, а если они здоровы, то болеют их дети. Поезда опаздывают. У велосипедов спускают колеса. И баги, по своей природе, непредсказаны.

Итак, мы не можем предсказать непредсказуемое. Однако есть жизнеспособная альтернатива: мы можем ожидать непредсказуемое, предвидеть его в некоторой степени, управлять им насколько это возможно и учитывать собственный опыт. Объятия непредсказуемости напоминают мне о парадоксе регулировщика из книги Джерри и Дэни Вайнбергов (Jerry and Dani Weinberg) "General Principles of System Design", который я упоминал ранее:

Задача регулировщика - устранить колебания, но эти колебания - единственный источник информации о качестве его работы. Поэтому, чем лучше работает регулировщик, тем меньше он получает информации о том, что и как улучшать.

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

Когда я был на мастер-классе Джерри Вайнберга "Problem Solving Leadership" (PSL), одна из групп не смогла выполнить очередное упражнение по решению проблем. Во время опроса Джерри спросил: "Почему у вас возникли такие трудности? Вчера вы справлялись с гораздо более трудными задачами."

"Нас сразила сложность проблемы" - ответил кто-то

Джерри посмотрел поверх своих очков и ответил: "Вас сразила ваша реакция на сложность проблемы"

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

В следующий раз мы посмотрим, как все это относится к тестированию и к оценкам тестов.

Комментариев нет:

Отправить комментарий