Джим Джонсон — основатель и председатель совета директоров Standish Group — уважаемой во всем мире компании, предоставляющей услуги по исследованию и анализу эффективности работы ИТ-проектов. Он широко известен, в первую очередь, благодаря исследованию «Почему проекты проваливаются?» и другим работам о системных затратах и доступности. Кроме того, он пионер современных исследовательских технологий, таких как виртуальные фокус-группы и техника аналитики прецедентов.
Несомненно, наибольшую славу Standish Group принесло их исследование The CHAOS Chronicles, в котором собран материал за 12 лет, состоящий из исследований более чем 50000 завершенных ИТ-проектов при помощи фокус-групп, детальных опросов и интервью руководителей высшего звена. Задачей этого исследования — зафиксировать масштаб провалов среди проектов разработки программных приложений, решающие факторы неуспешности и пути снижения подобных рисков. В 1994 году Standish Group опубликовала свой первый отчет по исследованию CHAOS, в котором зафиксированы факты траты милиардов долларов на проекты, которые так и не были завершены. С тех пор этот отчет наиболее часто цитируют в контексте данной отрасли.
Выделив немного времени во время отпуска, Джим Джонсон поговорил со мною на этой неделе о том, как это исследование проводилось, и о роли Agile-методов в контексте результатов исследования. К нам также присоединился Гордон Дивитт, исполнительный вице-президент корпорации Acxsys, ветеран производства ПО, участвовавший в мероприятиях CHAOS University с момента его основания.
Расскажите, пожалуйста, как составлялся первый отчет CHAOS?
Дж. Дж.: Мы довольно длительное время проводили исследование, так что давайте я расскажу немного и о нем тоже.
Первым нашим объектом изучения были продажи подпрограммного обеспечения — мы тогда вели группу IBM в Бельгии, около 100 человек, и никак не могли эти продажи корректно отследить. Я хочу сказать, когда вы продаете инструментальный пакет, то можете ожидать какого-то количества соглашений об использовании. Но мы не видели того, на что расчитывали, так что пришлось опрашивать людей о причинах, по которым такие соглашения не заключались. Они отвечали, что их проекты не будут закончены. На тот момент, по нашим данным, доля таких отмененных проектов составляла около 40%. То, о чем люди говорили, было настощей проблемой.
Потому мы начали проводить фокус-группы и т.п. для получения обратной связи, с тем, чтоб знать, как с этим бороться. Мы проводили опросы и тестирование для того, чтоб проверить надежность выборки, корректировали и улучшали ее, пока не получали такую выборку, которая была бы репрезентативной для разных отраслей и компаний различных размеров.
Вы считаете, что выборка CHAOS в целом репрезентативна в контексте разработки приложений?
Дж. Дж.: Да.
В таком случае, включает ли она, скажем, мелких производителей ПО?
Дж. Дж.: Ну, нет. Она состоит из следующих категорий: только государственные или коммерческие организации — без распространителей, поставщиков или консультантов. Так что Microsoft в нашей выборке не представлена. И организации с оборотом более 10 миллионов долларов также, за редкими исключениями, вроде компании Гордона.
Г. Д.: Участие в мероприятиях CHAOS University, похоже, ограничено для небольших компаний?
Дж. Дж.: Да, у нас действительно крупные клиенты. Но при этом мы, опрашивая людей, стараемся избегать предвзятости и покрыть всю отрасль. Мы не просто интервьюируем своих клиентов — мы платим людям за заполнение анкет, и это происходит совершенно отдельно. Понимаете, как церковь и государство (улыбается).
Вы платите людям за заполнение опросников?
Дж. Дж.: Ну, они приходят на фокус-группы, и мы оплачиваем их время. Если они заполняют опросник, мы выплачиваем им гонорар или дарим какой-то подарок. Это уже традиция в изучении этой отрасли. Таким образом мы получаем чистый результат, основанный на непредвзятых ответах. Если вы не платите, то вам будут отвечать предвзято, чтобы как-то повлиять на результат исследования. А оплата помогает сохранить нейтралитет мнений. Однако, многие жертвуют около четверти гонорара на благотворительные нужды — большинство тех, кто работает на государство, денег не берет ни в коем случае.
Да, мы используем прецеденты, когда от нас хотят аналитики, но мы не можем использовать эту информацию в рекламных целях или для собственных отчетов.
Главное качество получаемой нами информации — ее отграниченность от конкретной компании — все всегда сгруппировано, абсолютно конфиденциально, мы не указываем имен. Иначе мы не получили бы данных.
Г. Д.: Это собственность компании.
Дж. Дж.: Да, точно, и мы никогда не публикуем данные опросов.
Результаты вашего демографического исследования выложены на вашем сайте. Но, мне кажется, так кое-чего не хватает, а именно принципа, по которому вы отбираете компании для своей базы. Поскольку вы нацелены именно на неудачи в разработке, то ищите ли вы компании с каким-то особым типом неудач? Отбираете ли компании с более высоким процентом неудач, чем в среднем в ИТ-отрасли? Или они сами к вам обращаются? Или, если короче: ваша выборка репрезентативна для неудачных разработок в целом?
Дж. Дж.: Мы можем рассматривать серьезную неудачу в качестве прецедента для изучения, мы ищем именно поучительные неудачи. Но только не в качестве данных для опроса. Мы не запрашиваем «провальные» проекты. Наше первичное исследование было массированной расслыкой, основанной на широчайшей выборке, пожалуй, из-за того, что ответ на нее был крайне слабым (Прим. ред.: В исследовании 1994 года было предсталено более 8 тысяч проектов разработки приложений).
Сейчас мы приглашаем людей принять участие, используя свою базу SURF, и у нас есть определенные входных критерии.
Участники должны:
В нашей базе на данный момент около 3000 активных участников. Вы спросите, сами ли они вызвались исходя из того, что у них есть определенные проблемы, — но нет, я бы так не сказал. Думаю, они участвуют, потлому что это позволит им ознакомиться с данными — а их мы предоставляем только участникам. Но не думаю, что тут есть какая-то предвзятая заинтересованность… Я имею в виду, мы постоянно все пересматриваем, корректируем.
Корректируете? В каком смысле?
Дж. Дж.: Мы смотрим на данные, перезванием, чтобы что-то уточнить или исключить, если оно выглядит некорректно, или если мы не уверены. Что оно обладает необходимой достоверностью. Мы не просто базы наполняем, нам нужны четкие данные.
Результаты исследования CHAOS 2004: Распределение проектов
Сложные — 53%, успешные — 29%, провальные — 18%.
Как вы знаете, я писала обзор о том, как Роберт Гласс подвергает сомнению результаты CHAOS. Ваши цифры до того момента кто-либо подвергал сомнению?
Дж. Дж.: Не то чтобы. Чаще всего я слышу: «цифры слишком оптимистичные» — люди в основном удивлены. Их реакция на процент проектов, потерпевших неудачу (18%) из-за отмены или неиспользования результатов, вполне закономерна — они понимают причины этого явления: если все стремятся достичь успеха и придти к финишу первыми, то какое-то количество может к нему и не придти, так как находится на грани.
Всем известно, что самый распространенный сценарий в нашей отрасли — превысить бюджет, сорвать сроки, не обеспечить запланированную функциональность. Большинство это так комментирует: «Я не знаю ни одного проекта, где все было бы сделано вовремя».
Мы представили результаты своих исследований во множестве городов мира. Их можно найти в интернете. И не надо быть гением, чтоб понять нашу методологию — она известна всем.
Г. Д.: И еще никто не переходил обратно от сотрудничества к сомнениям — люди зависят от исследований, они уже 12 лет участвуют в мероприятиях и опросах. Они всегда возвращаются, а это о чем-то говорит.
У меня нет сомнений, что процесс вполне прозрачен, как это всегда было в CHAOS, и я могу подтвердить открытость Standish Group. И, что еще более важно, на мой взгляд, могу подтвердить принятие результатов клиентами — это подтверждают длительное их сотрудничество с группой и участие. Если бы было «неладно что-то в Датском королевстве», то это давно уже вышло бы на поверхность.
Вы упоминали как-то, что люди склонны путать сложные проекты и провальные — и я сама таким грешила — и что вы бы не советовали так считать. Не могли бы вы пару слов сказать на эту тему?
Дж. Дж.: Думаю, многие люди смешивают эти два понятия — сложные и провальные. Это ошибочно. Дело в том, что в одну кучу валят проекты, имеющие ценность, и такие, которые ценности не имеют. Я бы рассматривал проекты с позиции уровня ценности. Проект, превысивший планку в миллион долларов, мог бы обладать большей ценностью, поскольку новая система могла бы принести больше выгоды. С другой стороны, в сложных проектах много средств тратится впустую. Мы пытаемся отделить провал проекта от провала управления проектом, который все еще представляет ценность. Эта тема сейчас очень мне интересна, и именно ее раскрывают наши новые исследования.
Бывает «успешность», которая противоречит сразу трем параметрам — но проект все равно успешен и важен. Мы всегда спрашиваем: «Как бы объективно настроенный человек охарактеризовал этот проект?» Мы не хотим никого ставить в невыгодное положение… но если проект все же завершился, а не был закрыт, то он сложный, а не провальный. Тут непросто провести четкую границу.
Действительно, проекты так меняются со временем, что сложно получить достоверную информацио об исходном масштабе и конечном, например?
Дж. Дж.: Мы много усилий прилагаем для того, чтоб установить разницу между сложным проектом и успешным. И потом иногда перестраховываются: увеличивают бюджет проекта, чтоб избежать неудачи — на это мы тоже должны обращать внимание.
Десять факторов успеха
1. Вовлеченность пользователей
2. Поддержка руководителей высшего звена
3. Понятные бизнес-цели
4. Оптимизация масштаба
5. Гибкость рабочего процесса
6. Опытность руководителя проекта
7. Финансовый менеджмент
8. Опытные сотрудники
9. Формализированная методология
10. Стандартный инструментарий и инфраструктура
Ваше исследование неуспешности проектов — это попытка найти секрет успеха, не правда ли? Я заметила, что в вашем списке факторов успеха проекта под номером пять пункт «гибкость рабочего процесса». Имеется в виду, как при Agile-разработке ПО?
Дж. Дж.: Да, именно! Я большой поклонник Agile — использовал работу по итерациям в начале 90-х, и потом были отчеты CHAOS по быстрой отдаче. Мы очень болеем за небольшие проекты, маленькие команды, за Agile в техпроцессе. Кент Бэк читал лекции в CHAOS University, а я выступал на его семинарах. Я настоящий фанат экстремального программирования. В новой книге «Моя жизнь — провал» я говорю о Scrum, RUP, XP.
Г. Д.: Agile-методология помогла разбить проекты на более мелкие подпроекты. Даже если дела пойдут не так, вы сможете вовремя это понять. Не так как в старых проектах, работавших по методу водопада, когда ты зарываешься в нору, а плохие новости получаешь лишь через два года…
Дж. Дж.: Думаю в этом секрет — в пошаговости. Думаю, потому мы видим улучшения. (Прим. ред. Тут собрано несколько диаграмм, используемых Джимом Джонсоном на лекциях и взятых из его исследования 2004 года.)
Сравнение: Успешные, провальные, сложные.
Средний процент сверхзатрат за 1994-2004 годы.
Средний процент срыва сроков за 1994 – 2004 годы.
Большой проблемой было то, что проекты «разбухал», срывались сроки, перерасходовался бюджет, разрабатывалась ненужная функциональность. Особенно в государственных проектах. Agile-методология тут и правда помогает — проект почти не разрастается. Знаете, как говорят, «мне нужно это», а потом «это не настолько важно, как я раньше предполагал».
Г.Д.: Да, расстановка приоритетов для функциональности очень помогает… все время спрашивать, «а в чем бизнес-выгода?». Определить неценные характеристики продукта и оставить их в конце списка, и если руки до них никогда не дойдут, то, значит, они и вовсе не были нужны.
Вы собирали какие-нибудь данные об Agile в своих исследованиях?
Дж. Дж.: Да, мы пробовали. Надеюсь, кое-что из этого мы сможем показать. Я вставлял такие вопросы в опросники, но мало кто на них отвечал — по ним сложно получить однозначные данные. Мы пробовали добиться чего-то за пару исследований до теперешнего… надеюсь, в этот раз у нас получится. В течение нескольких дней мы сделаем последний подход к членам SURF, чтоб завершить исследование 2006 года.
Agile может породить новые вопросы. Как вы называете явление, когда запланированный масштаб достигнут для проекта с адаптивным планированием?
Дж. Дж.: Хороший вопрос. В случае компаний вроде Webex, Google, Amazon, eBay — сказать очень сложно, потому что у них «потоковые» обновления («pipelining»), а не релизы. «Что б мы за две недели не сделали, все пойдет в мир». Они успешны, потому что пользователи сталкиваются с незначительными изменениями. И, внедряя новые изменения, они защищены — помните, многие проекты терпят крах уже после того, как стадия разработки пройдена, и необходимо переходить ко внедрению.
Потоковые обновления? Звучит похоже на изменяемый масштаб.
Дж. Дж.: Да. Это очень познавательно, работать при изменяемом масштабе — люди гораздо счастливее, когда видят, что работа идет. Людям нравится наблюдать прогресси видеть результаты, и Agile — воплощение всего этого.
Г.Д.: Для этих компаний пользователи — молодые, увлеченные, легко адаптирующиеся, им нравятся перемены, нравится пробовать все новое. Большие банки не терпят такого подхода. Так я вижу этот процесс — не слишком ли грубо?
Дж. Дж.: Не всякая методология применима к любому проекту. Agile представляет для многих сложность, потому что у них непростая культура.
Г.Д.: Одна из вещей, которые мне нравятся в Agile — ты делаешь что-то, видишь это, пользователи говорят «мне нравится», или «мне не нравится, можете поменять?», или «нет, это неподходящий способ». У вас есть быстрая обратная связь и отладка качества на потоке получается намного лучше. При «водопадном» подходе, даже если доведешь проект до конца так, как предполагал, то все равно иммешь дело со всеми этими проблемами качества впоследствии. С Agile в тестировании и обратной связи качество улучшается.
Дж. Дж.: Люди считают, что Agile очень раскрепощает. Если бы они пригляделись, то увидели бы, что там все так же жестко, к при «водопаде» или еще чем-то, с чем имел бы дело Джеймс Мартин. Говорить, что за последний десяток лет не произошло улучшения — глупость. Мы достигли значительного прогресса.
Что ж, я обещала, что это будет последний вопрос. Кто возьмет заключительное слово?
Г.Д.: Вы знаете, Джим видный правдоборец, как и вся его команда. Вот что заставляет меня работать с ними.
Джим, спасибо большое, что уделили нашему разговору столько времени!
Несомненно, наибольшую славу Standish Group принесло их исследование The CHAOS Chronicles, в котором собран материал за 12 лет, состоящий из исследований более чем 50000 завершенных ИТ-проектов при помощи фокус-групп, детальных опросов и интервью руководителей высшего звена. Задачей этого исследования — зафиксировать масштаб провалов среди проектов разработки программных приложений, решающие факторы неуспешности и пути снижения подобных рисков. В 1994 году Standish Group опубликовала свой первый отчет по исследованию CHAOS, в котором зафиксированы факты траты милиардов долларов на проекты, которые так и не были завершены. С тех пор этот отчет наиболее часто цитируют в контексте данной отрасли.
Выделив немного времени во время отпуска, Джим Джонсон поговорил со мною на этой неделе о том, как это исследование проводилось, и о роли Agile-методов в контексте результатов исследования. К нам также присоединился Гордон Дивитт, исполнительный вице-президент корпорации Acxsys, ветеран производства ПО, участвовавший в мероприятиях CHAOS University с момента его основания.
Расскажите, пожалуйста, как составлялся первый отчет CHAOS?
Дж. Дж.: Мы довольно длительное время проводили исследование, так что давайте я расскажу немного и о нем тоже.
Первым нашим объектом изучения были продажи подпрограммного обеспечения — мы тогда вели группу IBM в Бельгии, около 100 человек, и никак не могли эти продажи корректно отследить. Я хочу сказать, когда вы продаете инструментальный пакет, то можете ожидать какого-то количества соглашений об использовании. Но мы не видели того, на что расчитывали, так что пришлось опрашивать людей о причинах, по которым такие соглашения не заключались. Они отвечали, что их проекты не будут закончены. На тот момент, по нашим данным, доля таких отмененных проектов составляла около 40%. То, о чем люди говорили, было настощей проблемой.
Потому мы начали проводить фокус-группы и т.п. для получения обратной связи, с тем, чтоб знать, как с этим бороться. Мы проводили опросы и тестирование для того, чтоб проверить надежность выборки, корректировали и улучшали ее, пока не получали такую выборку, которая была бы репрезентативной для разных отраслей и компаний различных размеров.
Вы считаете, что выборка CHAOS в целом репрезентативна в контексте разработки приложений?
Дж. Дж.: Да.
В таком случае, включает ли она, скажем, мелких производителей ПО?
Дж. Дж.: Ну, нет. Она состоит из следующих категорий: только государственные или коммерческие организации — без распространителей, поставщиков или консультантов. Так что Microsoft в нашей выборке не представлена. И организации с оборотом более 10 миллионов долларов также, за редкими исключениями, вроде компании Гордона.
Г. Д.: Участие в мероприятиях CHAOS University, похоже, ограничено для небольших компаний?
Дж. Дж.: Да, у нас действительно крупные клиенты. Но при этом мы, опрашивая людей, стараемся избегать предвзятости и покрыть всю отрасль. Мы не просто интервьюируем своих клиентов — мы платим людям за заполнение анкет, и это происходит совершенно отдельно. Понимаете, как церковь и государство (улыбается).
Вы платите людям за заполнение опросников?
Дж. Дж.: Ну, они приходят на фокус-группы, и мы оплачиваем их время. Если они заполняют опросник, мы выплачиваем им гонорар или дарим какой-то подарок. Это уже традиция в изучении этой отрасли. Таким образом мы получаем чистый результат, основанный на непредвзятых ответах. Если вы не платите, то вам будут отвечать предвзято, чтобы как-то повлиять на результат исследования. А оплата помогает сохранить нейтралитет мнений. Однако, многие жертвуют около четверти гонорара на благотворительные нужды — большинство тех, кто работает на государство, денег не берет ни в коем случае.
Да, мы используем прецеденты, когда от нас хотят аналитики, но мы не можем использовать эту информацию в рекламных целях или для собственных отчетов.
Главное качество получаемой нами информации — ее отграниченность от конкретной компании — все всегда сгруппировано, абсолютно конфиденциально, мы не указываем имен. Иначе мы не получили бы данных.
Г. Д.: Это собственность компании.
Дж. Дж.: Да, точно, и мы никогда не публикуем данные опросов.
Результаты вашего демографического исследования выложены на вашем сайте. Но, мне кажется, так кое-чего не хватает, а именно принципа, по которому вы отбираете компании для своей базы. Поскольку вы нацелены именно на неудачи в разработке, то ищите ли вы компании с каким-то особым типом неудач? Отбираете ли компании с более высоким процентом неудач, чем в среднем в ИТ-отрасли? Или они сами к вам обращаются? Или, если короче: ваша выборка репрезентативна для неудачных разработок в целом?
Дж. Дж.: Мы можем рассматривать серьезную неудачу в качестве прецедента для изучения, мы ищем именно поучительные неудачи. Но только не в качестве данных для опроса. Мы не запрашиваем «провальные» проекты. Наше первичное исследование было массированной расслыкой, основанной на широчайшей выборке, пожалуй, из-за того, что ответ на нее был крайне слабым (Прим. ред.: В исследовании 1994 года было предсталено более 8 тысяч проектов разработки приложений).
Сейчас мы приглашаем людей принять участие, используя свою базу SURF, и у нас есть определенные входных критерии.
Участники должны:
- иметь доступ к определенной информации о проекте
- использовать определенные приложения
- использовать определенные платформы.
В нашей базе на данный момент около 3000 активных участников. Вы спросите, сами ли они вызвались исходя из того, что у них есть определенные проблемы, — но нет, я бы так не сказал. Думаю, они участвуют, потлому что это позволит им ознакомиться с данными — а их мы предоставляем только участникам. Но не думаю, что тут есть какая-то предвзятая заинтересованность… Я имею в виду, мы постоянно все пересматриваем, корректируем.
Корректируете? В каком смысле?
Дж. Дж.: Мы смотрим на данные, перезванием, чтобы что-то уточнить или исключить, если оно выглядит некорректно, или если мы не уверены. Что оно обладает необходимой достоверностью. Мы не просто базы наполняем, нам нужны четкие данные.
Результаты исследования CHAOS 2004: Распределение проектов
Сложные — 53%, успешные — 29%, провальные — 18%.
Как вы знаете, я писала обзор о том, как Роберт Гласс подвергает сомнению результаты CHAOS. Ваши цифры до того момента кто-либо подвергал сомнению?
Дж. Дж.: Не то чтобы. Чаще всего я слышу: «цифры слишком оптимистичные» — люди в основном удивлены. Их реакция на процент проектов, потерпевших неудачу (18%) из-за отмены или неиспользования результатов, вполне закономерна — они понимают причины этого явления: если все стремятся достичь успеха и придти к финишу первыми, то какое-то количество может к нему и не придти, так как находится на грани.
Всем известно, что самый распространенный сценарий в нашей отрасли — превысить бюджет, сорвать сроки, не обеспечить запланированную функциональность. Большинство это так комментирует: «Я не знаю ни одного проекта, где все было бы сделано вовремя».
Мы представили результаты своих исследований во множестве городов мира. Их можно найти в интернете. И не надо быть гением, чтоб понять нашу методологию — она известна всем.
Г. Д.: И еще никто не переходил обратно от сотрудничества к сомнениям — люди зависят от исследований, они уже 12 лет участвуют в мероприятиях и опросах. Они всегда возвращаются, а это о чем-то говорит.
У меня нет сомнений, что процесс вполне прозрачен, как это всегда было в CHAOS, и я могу подтвердить открытость Standish Group. И, что еще более важно, на мой взгляд, могу подтвердить принятие результатов клиентами — это подтверждают длительное их сотрудничество с группой и участие. Если бы было «неладно что-то в Датском королевстве», то это давно уже вышло бы на поверхность.
Вы упоминали как-то, что люди склонны путать сложные проекты и провальные — и я сама таким грешила — и что вы бы не советовали так считать. Не могли бы вы пару слов сказать на эту тему?
Дж. Дж.: Думаю, многие люди смешивают эти два понятия — сложные и провальные. Это ошибочно. Дело в том, что в одну кучу валят проекты, имеющие ценность, и такие, которые ценности не имеют. Я бы рассматривал проекты с позиции уровня ценности. Проект, превысивший планку в миллион долларов, мог бы обладать большей ценностью, поскольку новая система могла бы принести больше выгоды. С другой стороны, в сложных проектах много средств тратится впустую. Мы пытаемся отделить провал проекта от провала управления проектом, который все еще представляет ценность. Эта тема сейчас очень мне интересна, и именно ее раскрывают наши новые исследования.
Бывает «успешность», которая противоречит сразу трем параметрам — но проект все равно успешен и важен. Мы всегда спрашиваем: «Как бы объективно настроенный человек охарактеризовал этот проект?» Мы не хотим никого ставить в невыгодное положение… но если проект все же завершился, а не был закрыт, то он сложный, а не провальный. Тут непросто провести четкую границу.
Действительно, проекты так меняются со временем, что сложно получить достоверную информацио об исходном масштабе и конечном, например?
Дж. Дж.: Мы много усилий прилагаем для того, чтоб установить разницу между сложным проектом и успешным. И потом иногда перестраховываются: увеличивают бюджет проекта, чтоб избежать неудачи — на это мы тоже должны обращать внимание.
Десять факторов успеха
1. Вовлеченность пользователей
2. Поддержка руководителей высшего звена
3. Понятные бизнес-цели
4. Оптимизация масштаба
5. Гибкость рабочего процесса
6. Опытность руководителя проекта
7. Финансовый менеджмент
8. Опытные сотрудники
9. Формализированная методология
10. Стандартный инструментарий и инфраструктура
Ваше исследование неуспешности проектов — это попытка найти секрет успеха, не правда ли? Я заметила, что в вашем списке факторов успеха проекта под номером пять пункт «гибкость рабочего процесса». Имеется в виду, как при Agile-разработке ПО?
Дж. Дж.: Да, именно! Я большой поклонник Agile — использовал работу по итерациям в начале 90-х, и потом были отчеты CHAOS по быстрой отдаче. Мы очень болеем за небольшие проекты, маленькие команды, за Agile в техпроцессе. Кент Бэк читал лекции в CHAOS University, а я выступал на его семинарах. Я настоящий фанат экстремального программирования. В новой книге «Моя жизнь — провал» я говорю о Scrum, RUP, XP.
Г. Д.: Agile-методология помогла разбить проекты на более мелкие подпроекты. Даже если дела пойдут не так, вы сможете вовремя это понять. Не так как в старых проектах, работавших по методу водопада, когда ты зарываешься в нору, а плохие новости получаешь лишь через два года…
Дж. Дж.: Думаю в этом секрет — в пошаговости. Думаю, потому мы видим улучшения. (Прим. ред. Тут собрано несколько диаграмм, используемых Джимом Джонсоном на лекциях и взятых из его исследования 2004 года.)
Сравнение: Успешные, провальные, сложные.
Средний процент сверхзатрат за 1994-2004 годы.
Средний процент срыва сроков за 1994 – 2004 годы.
Большой проблемой было то, что проекты «разбухал», срывались сроки, перерасходовался бюджет, разрабатывалась ненужная функциональность. Особенно в государственных проектах. Agile-методология тут и правда помогает — проект почти не разрастается. Знаете, как говорят, «мне нужно это», а потом «это не настолько важно, как я раньше предполагал».
Г.Д.: Да, расстановка приоритетов для функциональности очень помогает… все время спрашивать, «а в чем бизнес-выгода?». Определить неценные характеристики продукта и оставить их в конце списка, и если руки до них никогда не дойдут, то, значит, они и вовсе не были нужны.
Вы собирали какие-нибудь данные об Agile в своих исследованиях?
Дж. Дж.: Да, мы пробовали. Надеюсь, кое-что из этого мы сможем показать. Я вставлял такие вопросы в опросники, но мало кто на них отвечал — по ним сложно получить однозначные данные. Мы пробовали добиться чего-то за пару исследований до теперешнего… надеюсь, в этот раз у нас получится. В течение нескольких дней мы сделаем последний подход к членам SURF, чтоб завершить исследование 2006 года.
Agile может породить новые вопросы. Как вы называете явление, когда запланированный масштаб достигнут для проекта с адаптивным планированием?
Дж. Дж.: Хороший вопрос. В случае компаний вроде Webex, Google, Amazon, eBay — сказать очень сложно, потому что у них «потоковые» обновления («pipelining»), а не релизы. «Что б мы за две недели не сделали, все пойдет в мир». Они успешны, потому что пользователи сталкиваются с незначительными изменениями. И, внедряя новые изменения, они защищены — помните, многие проекты терпят крах уже после того, как стадия разработки пройдена, и необходимо переходить ко внедрению.
Потоковые обновления? Звучит похоже на изменяемый масштаб.
Дж. Дж.: Да. Это очень познавательно, работать при изменяемом масштабе — люди гораздо счастливее, когда видят, что работа идет. Людям нравится наблюдать прогресси видеть результаты, и Agile — воплощение всего этого.
Г.Д.: Для этих компаний пользователи — молодые, увлеченные, легко адаптирующиеся, им нравятся перемены, нравится пробовать все новое. Большие банки не терпят такого подхода. Так я вижу этот процесс — не слишком ли грубо?
Дж. Дж.: Не всякая методология применима к любому проекту. Agile представляет для многих сложность, потому что у них непростая культура.
Г.Д.: Одна из вещей, которые мне нравятся в Agile — ты делаешь что-то, видишь это, пользователи говорят «мне нравится», или «мне не нравится, можете поменять?», или «нет, это неподходящий способ». У вас есть быстрая обратная связь и отладка качества на потоке получается намного лучше. При «водопадном» подходе, даже если доведешь проект до конца так, как предполагал, то все равно иммешь дело со всеми этими проблемами качества впоследствии. С Agile в тестировании и обратной связи качество улучшается.
Дж. Дж.: Люди считают, что Agile очень раскрепощает. Если бы они пригляделись, то увидели бы, что там все так же жестко, к при «водопаде» или еще чем-то, с чем имел бы дело Джеймс Мартин. Говорить, что за последний десяток лет не произошло улучшения — глупость. Мы достигли значительного прогресса.
Что ж, я обещала, что это будет последний вопрос. Кто возьмет заключительное слово?
Г.Д.: Вы знаете, Джим видный правдоборец, как и вся его команда. Вот что заставляет меня работать с ними.
Джим, спасибо большое, что уделили нашему разговору столько времени!
