Как правило, наименее важные требования являются причиной наибольшего риска. Похоже, это является следствием их природы. Они меньше всего обдумываются, меньше всего анализируются и меньше всего осмысливаются, поэтому вероятность того, что именно они изменятся в процессе разработки, выше всего. Очень часто такие требования оказываются также наиболее рискованными с технической точки зрения.
В результате, если бизнес получает слишком большие полномочия, проект требует слишком много усилий и генерирует слишком много риска, при этом он обеспечивает слишком незначительную отдачу.
Разработчики
Можно подумать, что если большие полномочия предоставляются разработчикам, жизнь становится лучше. Но на самом деле это не так. В действительности результат получается такой же.
Когда разработчикам предоставляется чрезмерная свобода, они начинают использовать все те новые технологии и процессы, для которых у них никогда не хватает времени, если эти белые воротнички постоянно подгоняют их. Когда разработчикам предоставляется свобода, они устанавливают и начинают использовать новые инструменты разработки, новые языки программирования, новые технологии. При этом инструменты, языки и технологии выбираются исходя из того, что они очень интересны и суперсовременны. Все только что появившееся на рынке связано с риском. (Если мы не попробуем это сейчас, то когда же еще?)
Таким образом, в результате предоставления разработчикам слишком широких полномочий, они прикладывают слишком много усилий и генерируют слишком много риска, при этом они обеспечивают слишком незначительную отдачу.
Что делать?
Решение состоит в том, чтобы определенным образом разделить полномочия и ответственность между бизнесом и разработчиками. Бизнесмены должны принимать решения в своей области компетенции, а программисты должны принимать решения в своей области компетенции. Решения, принятые одной стороной, должны стать базой для решений, принимаемых другой стороной. Ни одна сторона не должна в одностороннем порядке решать абсолютно все.
Обеспечение подобного политического баланса может показаться невозможным. Если ООН не в состоянии добиться этого, то какие могут быть шансы у вас? Конечно же, если все, что у вас есть, – это туманная цель достижения баланса политических сил, тогда вы действительно остаетесь без шансов. Первая же сильная личность, которая появится на сцене, станет причиной нарушения баланса. К счастью, цель может быть гораздо более определенной, чем упомянутая.
Для начала небольшое отклонение от темы. Если кто-нибудь спросит у меня, какой автомобиль я хочу: Феррари или минивэн, я уверен, что выберу Феррари. Но если этот кто-то спросит у меня: Хочешь ли ты „Феррари" за 200 000 франков или минивэн за 40 000? – я начну формировать взвешенное решение. Если добавить к этому еще пару требований, например, мне необходимо брать с собой в дорогу пять детей или я должен быть способен развить скорость 200 километров в час, картина еще более прояснится. Существуют случаи, в которых каждое из решений по-своему оправданно, однако вы, скорее всего, не сможете сформировать хорошее решение исходя только лишь из глянцевых фотографий.
Вы должны знать, какими ресурсами вы обладаете, в чем вы ограничены и во что вам обойдется каждый из вариантов.
Следуя этой модели, бизнесмены должны определить:
• Объем работ или время выпуска версий продукта;
• Относительные приоритеты предполагаемых возможностей системы;
• Конкретный объем работ, связанных с предполагаемыми возможностями системы.
Для того чтобы помочь бизнесменам сформировать эти решения, разработчики должны сообщить:
• Оценки времени, необходимого для реализации различных возможностей системы.
• Предположительные последствия использования различных технических альтернатив.
• Процесс разработки, который соответствует их индивидуальности, их бизнес-окружению и культуре компании. Не существует списка пунктов типа: Вот так мы пишем программное обеспечение..., который бы подходил для абсолютно любой ситуации. Все это потому, что ситуация постоянно меняется.
• С использования какого набора методик они начнут свою работу и при помощи какого процесса они будут пересматривать эффекты использования этих методик и экспериментировать с изменениями. Это напоминает Американскую конституцию, которая устанавливает базовую философию, базовый набор правил (билль о правах и первые 10 поправок), а также правила изменения правил (добавления новых поправок).
Так как бизнес-решения формируются в течение всего времени жизни проекта, назначение бизнесменам ответственности за принятие бизнесрешений подразумевает, что заказчик является таким же членом команды разработчиков, как и любой другой программист. На практике для получения лучших результатов заказчик в течение всего рабочего времени сидит вместе с остальной командой и отвечает на возникающие у программистов вопросы.
Выбор технологии
Поначалу может показаться, что выбор технологии – это чисто техническое решение, но на самом деле это бизнес-решение, однако бизнесмены должны формировать его на основе сведений, предоставляемых разработчиками. Заказчик будет вынужден взаимодействовать с поставщиком базы данных или языка программирования в течение многих лет, поэтому он должен быть уверен в хороших с ним отношениях как на бизнес-уровне, так и на техническом уровне.
Если заказчик говорит мне: Мы хотим использовать вот эту реляционную базу данных и вот эту среду Java IDE, – я должен рассказать ему о последствиях подобного решения. Если я подозреваю, что объектно-ориентированная база данных и C++ лучшим образом подходят для данного проекта, я выполню оценку проекта с двух точек зрения. После этого бизнесмены получат возможность сформировать взвешенное бизнес-решение.
Однако существует еще одна сторона технологических решений, которая имеет прямое отношение к технарям, а не к бизнесменам. Как только технология начинает использоваться в рабочей среде компании, кто-то должен заниматься ее обслуживанием и поддержкой ее функционирования. Затраты, связанные с использованием пусть даже самой новейшей и самой совершенной технологии, – это не только затраты, связанные с разработкой системы на базе этой технологии. Эти затраты включают в себя также стоимость технической поддержки и обслуживания, одним словом, поддержки жизнедеятельности разработанной системы.
Что если это сложно?
В большинстве случаев решения, которые формируются в рамках этого процесса, на удивление просто воплотить в жизнь. Программисты отлично видят чудовищ, которые притаились за каждой из историй.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61