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

Шрифт:

-
+

Интервал:

-
+

Закладка:

Сделать
1 ... 18 19 20 21 22 23 24 25 26 ... 129
Перейти на страницу:

Это означает, что узлы информационных сетей (примерами которых будут человеческий мозг, интернет, социальные группы) сохраняют работоспособность даже в случае лишь частичного доступа ко всей сети, хотя производительность падает одновременно со снижением числа соединений. Точно к такому же выводу в своих исследования пришли Роб Кросс и Эндрю Паркер, опубликовавшие свои результаты в книге «Невидимая сила социальных связей»[16]. Они обнаружили, что вовсе не профессиональные знания людей будут самым надежным индикатором их результативности. Гораздо важнее количество и качество связей, которыми данный индивидуум обладает в организации [Cross 2004: 11].

Учитывая, что знания, используемые в проектах, в значительной степени неявные или подразумеваемые (не задокументированы и трудны для передачи), люди в организации должны передавать их друг другу посредством «осмотической коммуникации» в процессе совместной работы [Cockburn 2007: 202]. Следовательно, критически важно, чтобы люди, входящие в команду разработчиков, хотели сотрудничать друг с другом и делиться этими знаниями. (Мы вернемся к проблемам коммуникации в главе 12 и 13. В данный момент нас интересуют лишь аспекты, связанные с людьми.)

Разработчики ПО конвертируют информацию в инновации, и это полностью созвучно с фактом № 22 из книги Роберта Гласса «Факты и заблуждения профессионального программирования»:

80 % усилий по созданию ПО приходятся на интеллектуальную деятельность. Значительная часть этой деятельности креативна. И лишь небольшая часть – чисто техническая[17].

Профессия разработчиков ПО заключается в решении проблем. Гласс выполнял свои измерения на примере системных аналитиков, и мы уже знакомы с его выводом, что они проводят 80 % своего времени в размышлениях. Я думаю, что то же самое относится и ко всем остальным участникам проектных команд (может быть, за исключением некоторых бизнес-консультантов).

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

Креативность

Креативность – критически важная переменная в процессе создания ценности на основе знаний [Kao 2007]. Креативность заключается в способности отходить от шаблонных подходов при создании нового, предлагать новые ответы на основе старой информации и видеть решения там, где до этого никто их не видел. (Иногда это выглядит как кража старых идей и заметание следов, чтобы никто об этом не узнал.)

Важность знаний в качестве исходного сырья для креативности в настоящее время широко признается исследователями [Runco, Pritzker 1999]. Имеются подтверждения, что креативность в первую очередь базируется на знаниях людей и способности комбинировать несходные понятия, в результате чего возникают новые способы смотреть на вещи. С точки зрения наивных и неопытных наблюдателей, креативность часто похожа на магию. Но в реальности она возникает на плодородной почве знаний ценой многих часов тяжелого труда и размышлений.

Не существует единого определения креативности или общепринятого понимания ее природы. В литературе по психологии можно найти по меньшей мере 60 различных определений этого термина. Тем не менее существует достаточно распространенная точка зрения, что креативность проявляется в способности создавать идеи, которые одновременно оригинальны и полезны.

Оригинальность

Намерение (или надежда) многих разработчиков таково: решать проблемы, разрабатывая программное обеспечение, подобное которому еще никто никогда не создавал (при этом каждый из них хочет, чтобы это удалось именно ему, а не кому-нибудь другому!). Чтобы сделать каждую строчку кода уникальной, к их услугам такие методы, как объектно-ориентированное программирование, компонентное программирование, сервисно-ориентированная архитектура и рефакторинг. В глубине души разработчики полагают, что в идеальном мире каждый отрезок кода должен существовать в единственном экземпляре. В попытках реализовать эту утопию у них существенно больше возможностей, чем, например, у писателей, художников, архитекторов или парикмахеров. В арсенале представителей других креативных профессий нет такого разнообразия приемов. (Не исключено, что они даже не знают, что такое абстрактные конструкции или косвенная адресация.)

Полезность

Аналогичным образом второе намерение большинства разработчиков таково: создать полезное программное обеспечение. Вполне возможно, что ни один другой вид деятельности в сфере бизнеса не внес такой вклад в повышение глобальной производительности. Мне встречалось мнение, что ценность программных продуктов с точки зрения бизнеса на несколько порядков превышает ценность любых других креативных продуктов. И вряд ли с разработчиками ПО можно даже отдаленно сравнивать писателей, художников, архитекторов и парикмахеров. (Единственное исключение я готов сделать для рок-звезд.) При этом разработчики даже не считают себя «креативными» со всеми расплывчатыми коннотациями, которые связаны с этим словом. У большинства из них далеко не артистический темперамент. Они просто хотят создать нечто, чем будут пользоваться. (Не будем здесь говорить о том огромном количестве функционала, который создается ими в надежде, что он будет кому-нибудь нужен, но которым так никто и не пользуется.)

По всей видимости, в основе разработки программных продуктов лежит креативность, то есть создание продуктов одновременно оригинальных и полезных. Наиболее известная модель креативного процесса была предложена Грэмом Уоллесом и Ричардом Смитом в вышедшей в 1926 году книге «Искусство мыслить» (The Art of Thought). Описанный ими креативный процесс, включающий пять стадий, столь же применим к созданию ПО, как и к любому другому творческому процессу. Вообразим, например, что вам поручено улучшить работу сайта. В этом случае пять стадий креативного процесса могли бы выглядеть следующим образом:

1. Подготовка. Нахождение и определение измерения, в котором локализуется данная проблема; например, сколько времени уходит на выполнение (некоторых) запросов к серверу базы данных.

2. Обдумывание. Размышления о проблеме как в сознательном, так и в подсознательном режиме, например, когда вы принимаете душ, играете в покер и обсуждаете с друзьями последний фильм про Бэтмена (возможно, даже делая все это одновременно).

3. Интуитивное предчувствие. Осознание, что решение может быть найдено в улучшении модели данных, а не в более эффективной структуре запросов или более совершенном оборудовании, как вы думали до сих пор.

4. Озарение. Внезапное осознание, что решение может заключаться в «денормализации» некоторых таблиц базы данных, что ускорит обработку запросов.

1 ... 18 19 20 21 22 23 24 25 26 ... 129
Перейти на страницу:

Комментарии
Минимальная длина комментария - 20 знаков. Уважайте себя и других!
Комментариев еще нет. Хотите быть первым?