• Уверенность в успехе
Когда технологии, подходы и архитектура применяются впервые, мало кто из коллектива верит, что всё заработает. Это и понятно: в отсутствие опыта решения подобных проблем шансы на успех могут казаться призрачными. Однако такого рода сомнения могут стать источником реальных проблем. От недостатка уверенности в успехе проекта страдает не только боевой дух группы, но и производительность труда. Поэтому задача — как можно раньше исключить всякие сомнения и создать уверенность, что проект может быть и будет успешным.
• Прогноз проблем с производительностью
Почти всем ясно, что производительность приложений приобретает всё более важное значение. К сожалению, оптимизация производительности — это не та задача, которую можно отложить на потом, чтобы заняться ею в конце работы над проектом. Здесь нужен другой подход: следует заранее построить модель, воплощающую важнейшие черты архитектуры проекта, и как можно раньше протестировать её, чтобы выяснить, насколько хорошо она масштабируется.
• Прорывы в технологии
Чтобы работать на рынке с жёсткой конкуренцией необходимы исследования. Следует направить часть усилий группы на прогноз нужд потребителей, а также на поиск революционных решений и идей. Прекрасные идеи, новые подходы и хитовые приложения не появляются по волшебству в одночасье — их вынашивают как младенцев.
Исследования
Хоть некоторые и считают исследовательскую работу чисто академическим занятием, она тем не менее играет важную роль в разработке ПО. В этом разделе мы обсудим основы ведения исследований в приложении к созданию программных продуктов.
О чём пойдёт речь
Исследования бывают фундаментальные и прикладные. Первые — это процесс открытий и изобретений в надежде создать что-то полезное. Однако у результата такого исследования может и не быть коммерческого применения. С другой стороны, прикладное исследование на основе логических построений и анализа ситуации в некоторой отрасли ведёт поиск потенциально выгодных решений и пытается превратить гипотезы в конкретные идеи, которые помогут создать некоторый продукт.
Прикладные исследования — наиболее важная форма исследований в контексте этой книги. Они могут обеспечить критически важное преимущество в конкурентной борьбе, особенно на нестабильном рынке, когда потребности пользователей, ПО и аппаратные платформы и технологии претерпевают стремительные изменения. Хотя изменения часто вносят неопределённость, они также дают невероятные возможности группам, способным предвидеть потребности потребителей и задействовать новые технологии для их удовлетворения. Если, занимаясь созданием новой технологии, вы хотите «остаться на плаву» вопреки всем неожиданностям, то параллельно циклу разработки нужно вести непрерывную исследовательскую работу.
Из собственного опыта
Отладчик ядра SoftICE, созданный NuMega, был хитом на рынке программ для 16-разрядных платформ Microsoft DOS и Microsoft Windows. Нам даже без особых проблем удалось заставить его работать в Windows 95. Однако рынок неуклонно двигался к Windows NT, что вынудило нас заняться адаптацией SoftICE для работы с этой ОС, иначе рост прибылей нашей компании неизбежно снизился бы. Но эта задача казалась просто невыполнимой: новая система управлением виртуальной памятью Windows NT делала реализацию многих функций SoftICE чрезвычайно затруднительной и требовала от большинства участников группы разработчиков SoftICE знания недокументированных внутренних механизмов и структур данных Windows. Большинство работников компании (и не только они) сомневалось, что SoftICE когда-либо будет перенесён на Windows NT.
К счастью, среди нас оказался Фрэнк Гроссман, у которого хватило веры в осуществимость этой идеи и желания, чтобы провести соответствующие исследования. Он работал над этой проблемой день и ночь в течение двух недель, пока не создал довольно простой прототип, на примере которого смог продемонстрировать основные методики, необходимые для поддержки Windows NT. Ему достаточно было показать этот прототип группе, и дело было сделано: все поверили, что заставить SoftICE работать в Windows NT всё-таки можно. На реализацию сложных функций программы ушёл почти год, но в итоге мы создали продукт, в появление которого никто не верил. Проведённые исследования позволили нам не только обеспечить стремительный рост потока прибылей, но и воздвигнуть мощный барьер на пути у конкурентов, а полученные знания мы теперь можем использовать при разработке других продуктов.

Как это делается
Ниже описаны разные модели нахождения оптимального баланса между исследованиями и разработкой. Первая требует наименьшей затраты ресурсов, последняя — наибольшей. Если ваша компания невелика или просто не хватает ресурсов. можно начать с первой модели, по ходу дела она. может перерасти в другие.
• Проведение исследований во время работы над неосновными выпусками программы
Программные продукты развиваются циклически: сначала выходит основной выпуск, затем появляется ряд неосновных. Выход неосновного выпуска можно охарактеризовать как тактический шаг, т.е. в неосновных выпусках реализованы дополнительные функции и усовершенствования, улучшающие и расширяющие возможности продукта, уже присутствующего на рынке. Неосновные выпуски обычно появляются быстро, а их создание сопровождается меньшим риском, нежели создание основного выпуска. В силу своих особенностей неосновной выпуск — замечательный способ дать некоторым из ведущих разработчиков передышку от рутинных задач, во время которой у них есть шанс заняться исследовательской работой. Общее требование: к концу работы над неосновным выпуском исследование надо закончить.
Помимо самой возможности проведения исследований, совмещение исследований и работы над неосновными выпусками даёт участникам группы целый ряд других преимуществ. Ведущие разработчики могут перевести дух и заняться другими проблемами. Это реальная возможность дать главным «дарованиям» расслабиться, чтобы они не «перегорели», а другим членам коллектива — возможность выйти в лидеры. Взаимное обучение и возможность роста талантливых участников критичны для устранения текучести кадров и непрерывного роста мастерства группы.
• Дайте проявить себя каждому ведущему разработчику
Если вам посчастливилось иметь в группе двух и более способных ведущих программистов, пусть они сменяют друг друга на посту ведущего разработчика от выпуска к выпуску. В то время как один из них работает над новым выпуском, остальные могут заняться исследованием новых технологий и поиском новых идей. Разработчик, до этого занимавшийся исследованиями, несёт в группу энтузиазм и знания, накопленные за время исследований. Это пробуждает у других участников группы желание продолжить исследовательскую работу.
• Кандидатуры ведущих исследователей. Если сложность, размеры и число продуктов растут, то весьма вероятно, что вскоре понадобится провести ряд исследований. При этом надо подумать о найме исследователей или о переводе на исследовательскую работу некоторых специалистов высокого уровня. У последних, помимо профессиональной этики и способности к независимому мышлению и действию, должны быть развитые навыки общения. Таких людей непременно нужно включить в команду, разрабатывающую продукт, хотя не обязательно, чтоб они принимали участие в её работе ежедневно. Такое разделение обязанностей может дать замечательные результаты, но может стать и причиной отчуждения между командой разработчиков и исследователями. Ответственность за то, чтобы этого не произошло, целиком и полностью лежит на ведущих исследователях и менеджере проекта. Регулярное общение, как формальное, так и неформальное, снижает вероятность возникновения барьеров между группами.
Остаётся обсудить, на чём сосредоточить усилия исследователей. Если работа идёт в среде с небольшими ресурсами, позаботьтесь о том, чтобы шансы на успех исследовательской работы были максимальны. Следует разумно распределить усилия исследователей. В общем случае приоритетными являются следующие направления:
• Анализ тенденций и перспектив рынка
Каждые 3-4 года на рынке появляются новые, более совершенные технологии. Независимо от того, связаны ли новшества с графическим интерфейсом пользователя, клиент-серверными продуктами, моделями компонентных объектов или Интернетом, всегда следует идти в ногу с фундаментальными нововведениями и стараться, чтобы большие перемены не оставили вас позади. Направляйте исследования на поиск, анализ и мониторинг серьёзных изменений на рынке. Однако не заходите в своих исканиях так далеко, чтобы потерять связь с реальностью.
• Отбор новых идей
Новые идеи, связанные как с продуктами, так и с технологиями, могут приходить в любое время и из любых источников — и внутренних, и внешних. Одни идеи могут стоить миллионы, в то время как другие могут быть лишь напрасной тратой времени. У исследователей должен быть навык быстрого отбора хороших идей и отсеивания плохих.
• Анализ инноваций и направлений работы конкурентов
Одна из самых важных областей исследования — анализ инноваций и направлений работы конкурентов. Чтобы успешно состязаться с ними, надо понимать их технологии, знать их сильные и слабые стороны.
По завершении исследовательского проекта или при смене приоритетов исследования важно задокументировать результаты и сделать их доступными коллективу. Необходимо довести до сведения группы все без исключения результаты исследований, как положительные, так и отрицательные. Если исследовательский проект действительно обладает недюжинным потенциалом, было бы разумно создать прототип и продемонстрировать группе его возможности, пояснив принцип работы.
Из собственного опыта
К концу работы над BoundsChecker 3.0 энтузиазм нашего ведущего разработчика изрядно поубавился: проект отнял много времени и сил, и необходимость перемен была очевидна каждому его участнику. В это время возникла ещё одна задача: нужно было разобраться, что может дать новая технология от Microsoft под названием СОМ для наших продуктов. СОМ привлекла большое внимание, её даже считали «дорогой в будущее». Однако мы смутно представляли себе её суть, поэтому решено было взяться за обе проблемы одновременно.
В то время как остальная часть группы работала над следующим (неосновным) выпуском продукта, ведущий разработчик уделял все своё время изучению внутренней организации СОМ и моделированию новых функций BoundsChecker. Спустя три месяца, когда новая версия была практически завершена, главный разработчик был готов присоединиться к работе над BoundsChecker 4.0. Ему удалось не только восстановить свои силы, но и обучить остальных участников группы принципам работы с СОМ и показать им рабочие прототипы новых функций. Так что для начала наше положение было весьма неплохим: вовсю шли поставки BoundsChecker 3.0, только что закончена разработка версии 3.1, а мы уже обладали фундаментальной технологией для следующего выпуска программы.
Оценка технологий
Прежде чем приступать к проекту, обязательно нужно разобраться в технологии, намеченной для использования в нём. Это особенно важно для проектов, в реализации которых будут задействованы новые инструменты, компоненты, платформы или решении.
О чём пойдёт речь
Сегодня практически ни одна программа не создаётся на основе одной технологии. Например, в типичном современном Web-приложении используются функции ОС, графические библиотеки, компоненты от сторонних разработчиков, Web-серверы, серверы транзакций и баз данных, поэтому приходится разбираться в возможностях самых разных технологий. Следует ещё до начала работы над проектом выяснить, соответствуют ли возможности каждой намеченной для применения новой технологии нуждам проекта. Оценка технологий позволяет решать поставленные вопросы путём тестирования и совместного обсуждения, что позволяет обнаружить новые проблемы, о существовании которых никто даже не подозревал до начала использования этой технологии.
Просто удивительно, как часто разработчики считают, что для использования новых технологий достаточно одних предположений или сведений, полученных из прессы или телеконференций. Любая команда должна тщательно изучить все новые технологии, которые она собирается применить в работе над проектом. Если значительную долю задействованных в проекте технологий составляют новые (для рынка или для самой команды), до начала работы над проектом потребуется затратить некоторое время на изучение новых технологий.
Как это делается
Оценивая технологию, нужно дать ответы на следующие вопросы.
• Возможности технологии: обладает ли новая технология возможностями, необходимыми для реализации проекта?
• Качество: приемлем ли уровень качества технологии?
• Совершенство: обеспечивает ли технология должную производительность, масштабируемость и устойчивость?
• Поддержка: обеспечена ли новая технология адекватной поддержкой?
• Простота использования: не слишком ли сложна новая технология в использовании и при отладке?
• Профессионализм команды: хватит ли у команды мастерства для применения этой технологии?
На самом деле собственно процесс оценки технологии не столь сложен, но нужно провести его довольно быстро, поскольку помимо всего прочего, именно результаты оценки технологий определяют срок утверждения окончательного плана проекта. Даже если время для вас — роскошь, при оценке любой технологии не забывайте:
• формулировать критерии: определяйте свои потребности заранее и делайте это как можно точнее с помощью критериев, данных выше;
• использовать сформулированные критерии при оценке: объективно оценивайте результаты, опираясь на факты, а не на мнения;
• учитывать отзывы заказчиков: собирайте отзывы заказчиков (как положительные, так и отрицательные) о результатах оценки; не забывайте интересоваться мнением заказчиков: удовлетворят ли новые технологии их нужды.
Моделирование
В начале работы над проектом почти всегда возникает ряд важных вопросов, связанных с реализацией той или иной технологии. Моделирование — важная методика, которая поможет получить необходимые ответы.
О чём пойдёт речь
Создание прототипа — важный этап, который любая группа разработчиков может осуществить ещё до начала работы над проектом. Работа с прототипом поможет понять, как эффективно воплотить ключевые функции программы, оценить сложность реализации ключевых технологий и необходимое для этого время, а также свести к минимуму общий риск ошибок и срыва планов.
Рассмотрим примеры того, что может случиться, если отказаться от работы с прототипом, Определив все компоненты программы, команда решила сначала реализовать её инфраструктуру, так как без этого компонента, обычно самого важного и самого сложного, ничего не работает. В результате этот компонент был спроектирован и построен без предварительной работы с прототипом. Когда он был готов, группа решила подключить к нему другие. Но после интеграции новых компонентов стало ясно, что возможности инфраструктуры недостаточны, конструкция её плоха или не масштабируется. После этого приходится искать места, где и что пошло не так, проектировать и кодировать все заново. Перепроектирование программы и изменение её кода во время цикла разработки, очевидно, приведёт к задержке выпуска ПО.
Рассмотрим ещё один пример, на сей раз с противоположным сценарием. Участники группы отдают себе отчёт в том, что нельзя строить компоненты инфраструктуры проекта, не поняв технических требований других частей системы, поэтому решено сначала создать полную спецификацию системы. Но эта задача оказалась затруднительной, так как не все проблемы, с которыми придётся столкнуться, известны заранее. Фактически здесь возникают сплошные вопросы, на которые никто не знает ответа. Конечно, можно попытаться действовать наугад в надежде, что всё будет хорошо, но это слишком рискованно.
Все эти проблемы позволяет решить прототип. В первом примере работа с прототипом помогла бы заранее смоделировать систему. Это позволило бы понять, как собрать все компоненты. Во втором примере работа с прототипом подсказала бы проектные решения.
Из собственного опыта
Оба рассмотренных выше примера взяты из работы над реальными проектами. На заре нашей деятельности мы не уделяли должного внимания созданию прототипов тех элементов, использование которых таило в себе наибольший риск или неопределённость. Оглядываясь в прошлое, понимаешь, что всех проблем удалось бы избежать, если бы конструкция программы была заранее проверена с помощью прототипа.
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