Решения, принятые одной стороной, должны стать базой для решений, принимаемых другой стороной. Ни одна сторона не должна в одностороннем порядке решать абсолютно все.
Обеспечение подобного политического баланса может показаться невозможным. Если ООН не в состоянии добиться этого, то какие могут быть шансы у вас? Конечно же, если все, что у вас есть, – это туманная цель достижения баланса политических сил, тогда вы действительно остаетесь без шансов. Первая же сильная личность, которая появится на сцене, станет причиной нарушения баланса. К счастью, цель может быть гораздо более определенной, чем упомянутая.
Для начала небольшое отклонение от темы. Если кто-нибудь спросит у меня, какой автомобиль я хочу: Феррари или минивэн, я уверен, что выберу Феррари. Но если этот кто-то спросит у меня: Хочешь ли ты „Феррари" за 200 000 франков или минивэн за 40 000? – я начну формировать взвешенное решение. Если добавить к этому еще пару требований, например, мне необходимо брать с собой в дорогу пять детей или я должен быть способен развить скорость 200 километров в час, картина еще более прояснится. Существуют случаи, в которых каждое из решений по-своему оправданно, однако вы, скорее всего, не сможете сформировать хорошее решение исходя только лишь из глянцевых фотографий.
Вы должны знать, какими ресурсами вы обладаете, в чем вы ограничены и во что вам обойдется каждый из вариантов.
Следуя этой модели, бизнесмены должны определить:
• Объем работ или время выпуска версий продукта;
• Относительные приоритеты предполагаемых возможностей системы;
• Конкретный объем работ, связанных с предполагаемыми возможностями системы.
Для того чтобы помочь бизнесменам сформировать эти решения, разработчики должны сообщить:
• Оценки времени, необходимого для реализации различных возможностей системы.
• Предположительные последствия использования различных технических альтернатив.
• Процесс разработки, который соответствует их индивидуальности, их бизнес-окружению и культуре компании. Не существует списка пунктов типа: Вот так мы пишем программное обеспечение..., который бы подходил для абсолютно любой ситуации. Все это потому, что ситуация постоянно меняется.
• С использования какого набора методик они начнут свою работу и при помощи какого процесса они будут пересматривать эффекты использования этих методик и экспериментировать с изменениями. Это напоминает Американскую конституцию, которая устанавливает базовую философию, базовый набор правил (билль о правах и первые 10 поправок), а также правила изменения правил (добавления новых поправок).
Так как бизнес-решения формируются в течение всего времени жизни проекта, назначение бизнесменам ответственности за принятие бизнесрешений подразумевает, что заказчик является таким же членом команды разработчиков, как и любой другой программист. На практике для получения лучших результатов заказчик в течение всего рабочего времени сидит вместе с остальной командой и отвечает на возникающие у программистов вопросы.
Выбор технологии
Поначалу может показаться, что выбор технологии – это чисто техническое решение, но на самом деле это бизнес-решение, однако бизнесмены должны формировать его на основе сведений, предоставляемых разработчиками. Заказчик будет вынужден взаимодействовать с поставщиком базы данных или языка программирования в течение многих лет, поэтому он должен быть уверен в хороших с ним отношениях как на бизнес-уровне, так и на техническом уровне.
Если заказчик говорит мне: Мы хотим использовать вот эту реляционную базу данных и вот эту среду Java IDE, – я должен рассказать ему о последствиях подобного решения. Если я подозреваю, что объектно-ориентированная база данных и C++ лучшим образом подходят для данного проекта, я выполню оценку проекта с двух точек зрения. После этого бизнесмены получат возможность сформировать взвешенное бизнес-решение.
Однако существует еще одна сторона технологических решений, которая имеет прямое отношение к технарям, а не к бизнесменам. Как только технология начинает использоваться в рабочей среде компании, кто-то должен заниматься ее обслуживанием и поддержкой ее функционирования. Затраты, связанные с использованием пусть даже самой новейшей и самой совершенной технологии, – это не только затраты, связанные с разработкой системы на базе этой технологии. Эти затраты включают в себя также стоимость технической поддержки и обслуживания, одним словом, поддержки жизнедеятельности разработанной системы.
Что если это сложно?
В большинстве случаев решения, которые формируются в рамках этого процесса, на удивление просто воплотить в жизнь. Программисты отлично видят чудовищ, которые притаились за каждой из историй. Бизнесмены часто говорят: Я и не думал, что это будет настолько дорого. Давайте сделаем это же самое, только на треть. Я полагаю, что на текущий момент этого будет достаточно.
Однако в некоторых случаях подобный способ не срабатывает. В некоторых ситуациях наименьшая ценная часть разработки с точки зрения бизнеса выглядит большой и рискованной с точки зрения программиста. Когда такое происходит, вы не должны допускать каких-либо сомнений. Вы обязаны действовать осторожно. Допускается сделать лишь незначительное количество ошибок. Вы можете потребовать большее количество внешних ресурсов, однако может случиться так, что вы получите эти ресурсы только тогда, когда времени будет в обрез. Поэтому с самого начала вы должны сделать все, что в ваших силах, для того, чтобы сократить объем работ. Вы должны сделать все, что в ваших силах для того, чтобы снизить риск. Когда все это будет сделано, вы можете приступать к работе.
Об этом можно сказать и по-другому: разделение полномочий между бизнесом и разработчиком – это не оправдание отказа от выполнения грязной работы. Совсем наоборот. Это способ отделения той работы, которая очевидно является сложной, от той работы, про которую вы просто еще не придумали, как сделать ее простой. В большинстве случаев работа оказывается проще, чем вам кажется с самого начала. Если это не так, вы обязаны сделать работу в любом случае, так как именно за это вам и платят деньги.
Глава 15.
Стратегия планирования
Мы будем планировать нашу работу следующим образом: сначала мы быстро сформируем общий план, затем мы будем постоянно пересматривать его, формируя более конкретные цели для более коротких сроков: лет, месяцев, недель и дней. Мы будем формировать план быстро и с минимальными затратами, поэтому если нам потребуется изменить его, мы должны будем преодолеть минимальную инерцию.
Планирование – это процесс предположения, как будет выглядеть процесс разработки программного продукта для заказчика. Вот некоторые цели, которые достигаются в процессе планирования:
• Собрать команду вместе;
• Определить объем работ и приоритеты;
• Оценить затраты и график работ;
• Добиться появления у каждого заинтересованного лица ощущения того, что система действительно может быть реализована;
• Определить исходные данные для обратной связи.
Давайте взглянем на принципы, которые влияют на планирование. Некоторые из них являются базовыми принципами, о которых шла речь в главе 8.
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
Обеспечение подобного политического баланса может показаться невозможным. Если ООН не в состоянии добиться этого, то какие могут быть шансы у вас? Конечно же, если все, что у вас есть, – это туманная цель достижения баланса политических сил, тогда вы действительно остаетесь без шансов. Первая же сильная личность, которая появится на сцене, станет причиной нарушения баланса. К счастью, цель может быть гораздо более определенной, чем упомянутая.
Для начала небольшое отклонение от темы. Если кто-нибудь спросит у меня, какой автомобиль я хочу: Феррари или минивэн, я уверен, что выберу Феррари. Но если этот кто-то спросит у меня: Хочешь ли ты „Феррари" за 200 000 франков или минивэн за 40 000? – я начну формировать взвешенное решение. Если добавить к этому еще пару требований, например, мне необходимо брать с собой в дорогу пять детей или я должен быть способен развить скорость 200 километров в час, картина еще более прояснится. Существуют случаи, в которых каждое из решений по-своему оправданно, однако вы, скорее всего, не сможете сформировать хорошее решение исходя только лишь из глянцевых фотографий.
Вы должны знать, какими ресурсами вы обладаете, в чем вы ограничены и во что вам обойдется каждый из вариантов.
Следуя этой модели, бизнесмены должны определить:
• Объем работ или время выпуска версий продукта;
• Относительные приоритеты предполагаемых возможностей системы;
• Конкретный объем работ, связанных с предполагаемыми возможностями системы.
Для того чтобы помочь бизнесменам сформировать эти решения, разработчики должны сообщить:
• Оценки времени, необходимого для реализации различных возможностей системы.
• Предположительные последствия использования различных технических альтернатив.
• Процесс разработки, который соответствует их индивидуальности, их бизнес-окружению и культуре компании. Не существует списка пунктов типа: Вот так мы пишем программное обеспечение..., который бы подходил для абсолютно любой ситуации. Все это потому, что ситуация постоянно меняется.
• С использования какого набора методик они начнут свою работу и при помощи какого процесса они будут пересматривать эффекты использования этих методик и экспериментировать с изменениями. Это напоминает Американскую конституцию, которая устанавливает базовую философию, базовый набор правил (билль о правах и первые 10 поправок), а также правила изменения правил (добавления новых поправок).
Так как бизнес-решения формируются в течение всего времени жизни проекта, назначение бизнесменам ответственности за принятие бизнесрешений подразумевает, что заказчик является таким же членом команды разработчиков, как и любой другой программист. На практике для получения лучших результатов заказчик в течение всего рабочего времени сидит вместе с остальной командой и отвечает на возникающие у программистов вопросы.
Выбор технологии
Поначалу может показаться, что выбор технологии – это чисто техническое решение, но на самом деле это бизнес-решение, однако бизнесмены должны формировать его на основе сведений, предоставляемых разработчиками. Заказчик будет вынужден взаимодействовать с поставщиком базы данных или языка программирования в течение многих лет, поэтому он должен быть уверен в хороших с ним отношениях как на бизнес-уровне, так и на техническом уровне.
Если заказчик говорит мне: Мы хотим использовать вот эту реляционную базу данных и вот эту среду Java IDE, – я должен рассказать ему о последствиях подобного решения. Если я подозреваю, что объектно-ориентированная база данных и C++ лучшим образом подходят для данного проекта, я выполню оценку проекта с двух точек зрения. После этого бизнесмены получат возможность сформировать взвешенное бизнес-решение.
Однако существует еще одна сторона технологических решений, которая имеет прямое отношение к технарям, а не к бизнесменам. Как только технология начинает использоваться в рабочей среде компании, кто-то должен заниматься ее обслуживанием и поддержкой ее функционирования. Затраты, связанные с использованием пусть даже самой новейшей и самой совершенной технологии, – это не только затраты, связанные с разработкой системы на базе этой технологии. Эти затраты включают в себя также стоимость технической поддержки и обслуживания, одним словом, поддержки жизнедеятельности разработанной системы.
Что если это сложно?
В большинстве случаев решения, которые формируются в рамках этого процесса, на удивление просто воплотить в жизнь. Программисты отлично видят чудовищ, которые притаились за каждой из историй. Бизнесмены часто говорят: Я и не думал, что это будет настолько дорого. Давайте сделаем это же самое, только на треть. Я полагаю, что на текущий момент этого будет достаточно.
Однако в некоторых случаях подобный способ не срабатывает. В некоторых ситуациях наименьшая ценная часть разработки с точки зрения бизнеса выглядит большой и рискованной с точки зрения программиста. Когда такое происходит, вы не должны допускать каких-либо сомнений. Вы обязаны действовать осторожно. Допускается сделать лишь незначительное количество ошибок. Вы можете потребовать большее количество внешних ресурсов, однако может случиться так, что вы получите эти ресурсы только тогда, когда времени будет в обрез. Поэтому с самого начала вы должны сделать все, что в ваших силах, для того, чтобы сократить объем работ. Вы должны сделать все, что в ваших силах для того, чтобы снизить риск. Когда все это будет сделано, вы можете приступать к работе.
Об этом можно сказать и по-другому: разделение полномочий между бизнесом и разработчиком – это не оправдание отказа от выполнения грязной работы. Совсем наоборот. Это способ отделения той работы, которая очевидно является сложной, от той работы, про которую вы просто еще не придумали, как сделать ее простой. В большинстве случаев работа оказывается проще, чем вам кажется с самого начала. Если это не так, вы обязаны сделать работу в любом случае, так как именно за это вам и платят деньги.
Глава 15.
Стратегия планирования
Мы будем планировать нашу работу следующим образом: сначала мы быстро сформируем общий план, затем мы будем постоянно пересматривать его, формируя более конкретные цели для более коротких сроков: лет, месяцев, недель и дней. Мы будем формировать план быстро и с минимальными затратами, поэтому если нам потребуется изменить его, мы должны будем преодолеть минимальную инерцию.
Планирование – это процесс предположения, как будет выглядеть процесс разработки программного продукта для заказчика. Вот некоторые цели, которые достигаются в процессе планирования:
• Собрать команду вместе;
• Определить объем работ и приоритеты;
• Оценить затраты и график работ;
• Добиться появления у каждого заинтересованного лица ощущения того, что система действительно может быть реализована;
• Определить исходные данные для обратной связи.
Давайте взглянем на принципы, которые влияют на планирование. Некоторые из них являются базовыми принципами, о которых шла речь в главе 8.
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