Есть множество исследований по поводу того, как происходит распространение инноваций в мире. Согласно большинству из них, большинству отраслей требуется 10-15 лет для принятия инноваций, но проблема в том, что в области разработки ПО этот срок существенно выше.
На самом деле, в нашей области нового существенно меньше, чем может показаться, и если посмотреть на «современные» методики разработки или технологии, то окажется, что исследования в этой области появились 10, 20, 30, а то и более назад.
Исследователи выделяют 5 категорий людей, в зависимости от их отношения к инновациям [Макконнелл2003]:
Инноваторы – это энтузиасты со склонностью к экспериментам. Они любят испытывать новые технологии независимо от степени их готовности и сопутствующего им риска. Их не волнует значительная степень неопределенности при использовании еще не сложившихся новых технологий и методик. Поскольку они рискуют, их часто преследуют неудачи.
Эксперты – это лидеры в своей организации, их мнение уважают. Они опережают остальных в принятии инноваций, но ровно настолько, чтобы служить примером и увлекать других.
Люди из категории раннего большинства более рассудительны и внимательны в принятии инноваций, чем эксперты, и относятся к одной из двух крупнейших групп. Чтобы решиться на использование инноваций, им нужно больше времени, чем экспертам. Они обычно следуют по стопам категории экспертов.
Позднее большинство настроено по отношению к инновациям скептически. Оно ведет себя очень осторожно и принимает инновации только после того, как они многими опробованы. Эти люди не убеждены, что инновации приводят к улучшениям или что они применимы в их случае. Принятие ими инноваций может зависеть от желания не отставать от коллег.
Медлящие – последние в принятии инноваций; они скорее смотрят в прошлое, чем в будущее. Люди этой категории чрезвычайно осторожны, принимая новое.
При этом, если изобразить это графически, то получится такая картина:
Тут интересно несколько моментов. Во-первых, интересна пропасть между экспертами и ранним большинством. В наших реалиях это проявляется в том, что «гики» начинают использовать методологию или технологию значительно раньше, но требуется существенные усилия, чтобы эта «инновация» стала мейнстримом. Достаточно вспомнить переходы с одной парадигмы программирования на другую или внедрение новых методологий разработки ПО. Между первыми успешными попытками и внедрением в массы может пройти десяток лет, и данная пропасть является одним из объяснений такого положения дел.
Во-вторых, интересно, чем обусловлен столь медленный процесс принятия инноваций в такой, казалось бы, инновационной области, как разработка ПО? Как мне кажется, что причина такого положения дел в том, что невероятно сложно доказать, что причина успеха проекта кроется именно в применении этого инновационного инструмента, новой методологии разработки, технологии, языка программирования или парадигмы. А значит, у нас не будет убедительных аргументов, чтобы преодолеть скептицизм и инерционность большинства команд и их менеджеров.
Появление пенициллина сразу же доказало свою эффективность, но этого нельзя сказать о появлении новшеств в разработке ПО. Работы по управлению рисками, итеративный процесс разработки или вовлечение заказчика в работу команды впервые были опробованы в 70-х годах прошлого века, но стали «мейнстримом» лишь с популяризацией гибких методологий. Труды по объектно-ориентированному программированию или по проектированию по контракту появились 30 и более лет назад, а контрактное программирование так и не сумело занять свою нишу среди обычных разработчиков. Функциональное программирование вообще появилось на заре компьютерной эры и лишь спустя 60 лет оно стало действительно продвигаться в массы.
У того же Стива Макконнелла есть замечательные мысли по этому поводу: «Вопрос не в стиле разработки ПО, а в компетентности. Реальная разница не в том, какой стиль выбран, а в том, каким уровнем образования, квалификации и понимания обладают участники проекта. Вместо того чтобы спорить о достоинствах стилей, надо искать пути повышения среднего уровня разработчиков и компетентности менеджеров. Это увеличит шансы на успех проекта не зависимо от того, какой стиль выбран.»
При этом компетенция команды является ключом не только к успеху проекта, но и к простоте внедрения инноваций, ведь высококлассная команда содержит большее число экспертов. Эксперт по своему опыту знает, что новое – это хорошо забытое старое и умело использует повторно свой опыт и знания, что значительно упрощает переход на новый инструмент или технологию. Кроме того, эксперт не боится уходить от старой технологии, поскольку при этом не падает его рыночная стоимость и профессионализм в глазах коллег. Большинство программистов, потратив на свой любимый язык десятки лет, будут ожесточенно доказывать его преимущество перед новым творением, ведь они защищают не столько этот язык перед оппонентом, сколько свою ценность перед программистским сообществом.
Если же мы вернемся к «средней» команде, то успех такого проекта – это слишком сложная функция от огромного количества переменных и улучшение одной из них, едва ли сможет этот успех гарантировать. К тому же, чем меньше экспертов в команде тем ниже шансы на корректное использование этого инструмента, ведь чтобы от него была польза, инструментом нужно пользоваться умело, а не просто рассчитывать на его волшебную силу, толком не понимая его возможностей и назначения.
Так что выходит, что залогом внедрения инноваций является ваше постоянное развитие, ну а по поводу проблемы бездумного использования инструментов мы поговорим в следующий раз.
Комментариев нет:
Отправить комментарий