Текст книги "Время — деньги. Создание команды разработчиков программного обеспечения"

Автор книги: Эд Салливан

сообщить о нарушении

Текущая страница: 12 (всего у книги 19 страниц)

Анализ требований

Когда требования сформулированы, но ещё не утверждены, разумно проанализировать их в целом и каждое по отдельности. Требования к новой программе нужно отбирать очень тщательно. Многие просто берут список требований, не анализируя его с точки зрения коммерческой привлекательности и не удаляя всё, что не вписывается в центральную идею проекта. В итоге получаются программы с плохо организованной функциональностью, не соответствующей назначению программы. Оценке требований и поиску направления, в котором движется разработка вашей программы, должно уделять большое внимание.

«Фрагментация» требований

Отойти от намеченного пути при формулировании требований легко. Так бывает, когда упрямый индивид или целая группа уводит «фокус» требований совсем в другую сторону, чем было задумано. Возможно, было легче формулировать требования для тех функций, определить которые было проще всего. Может оказаться и так, что требования сопряжены с чрезмерным для таких программ риском. Как бы ни было, обязательно должны присутствовать объективный взгляд на требования и оценка их влияния на ход проекта.

Категории требований

Ниже описаны четыре категории требований.

• «Опережающие» и «догоняющие» требования

Первые позволяют продукту обогнать конкурентов по рынку. Они могут описывать просто новое представление данных или возможность поддержки новой платформы. Им не обязательно быть революционными – достаточно, что они дают преимущество в конкуренции на момент выхода программы на рынок. Вторые подтягивают функциональность программы до уровня конкурентов. Они призваны сохранить конкурентоспособность и связаны с решением проблем сбыта и технической поддержки.

Разделение требований на категории «опережающих» и «догоняющих» позволяет проанализировать конкурентоспособность вашей программы. Например, если выяснилось, что в программе реализовано слишком мало опережающих требований или их вообще нет, можно реализовать дополнительные опережающие требования. Стратегия разработки программ в NuMega всегда включает ряд особенностей, которые делают программу уникальной на рынке и позволяют ей стать или остаться, так сказать, «чемпионом породы».

• Перспективные и ретроспективные требования

Последние направлены на решение проблем, связанных с прошлыми выпусками ПО. Например, для решения проблем с производительностью и удобством использования в последнем выпуске в общем случае служат ретроспективные требования. Так как эти требования – не что иное, как реакция на существующий продукт в существующем окружении, их реализация позволяет улучшить продукт, но не предвосхитить будущие потребности.

Перспективные требования позволяют заранее побеспокоиться о будущих потребностях заказчика. Они основаны на уверенности в том, что заказчик обязательно изменит свои потребности и желания, даже если сам он ещё об этом не знает. Часто перспективные требования базируются на крупномасштабных изменениях в деловой практике (например, на повсеместном внедрении размещения заказов через Web), технологиях (появление платформ, поддерживающих беспроводную связь) или рынка (слияние двух конкурировавших фирм). Перспективные требования труднее всего сформулировать, но, если удастся верно предугадать нужды потребителя и не ошибиться с выбором рынка и функций ПО, результатом будет значительное преимущество перед конкурентами.

Подборка ретроспективных и перспективных требований должна соответствовать потребностям, которые призван удовлетворить продукт, особенностям рынка и задачам выпуска. Скажем, можно быстро (за полгода) подготовить выпуск, в котором будет реализован ряд ретроспективных требований, а также включить в него несколько перспективных требований, чтобы не упустить какую-то интересную возможность.

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

Наглядное представление требований

Чтобы понять сформулированные требования в общем, можно использовать таблицу для анализа требований, расписав их по ячейкам таблицы. Эта таблица имеет вид квадрата. поделённого на четыре равные части. Ниже по одной оси находятся догоняющие и опережающие требования, а по другой – перспективные и ретроспективные требования (рис. 8-2).

Рис. 8-2. Набор требований, представленный в виде таблицы из четырёх ячеек.

Далее приводится описание содержимого каждой ячейки таблицы. Расписав собственные требования по ячейкам такой таблицы, вы поймёте, в каком направлении пойдёт работа.

Ячейка 1. Вы предвидите будущие потребности потребителей и будете первым производителем, предоставившим соответствующее решение. Эти потребности пока ещё не до конца поняты и не полностью установлены. Вы первопроходец в этой области, поэтому уровень риска довольно высок. Из-за множества «неизвестных» нельзя заранее предоставить подробное определение требований. Основное внимание должно быть уделено созданию и последовательному улучшению прототипа ПО. Потребуется очень быстро пересматривать структуру ПО в процессе разработки, привлечь для тестирования реальных пользователей и обновить требования до начала этапа планирования.

Ячейка 2. Ряд возможностей ПО, созданного конкурентами, предвосхищают нужды потребителей, поэтому хотелось бы наверстать упущенное. Следует изучить предложения конкурентов, понять, что они сделали правильно, а что – нет, и извлечь урок из допущенных ими ошибок. Риск, связанный с требованиями из этой ячейки, меньше в сравнении с риском в ячейке 1, так как уже существуют программные продукты, способные стать материалом для изучения и извлечения уроков. Однако следует ожидать быстрого изменения рынка и потребностей клиентов, поэтому, прежде чем перейти к формализации требований и созданию плана проекта, придётся затратить много усилий на моделирование технических характеристик и анализ удобства использования.

Ячейка 3. Наверное, реализация требований из этой ячейки доставит меньше всего хлопот, так как нужно предоставить уникальный в отраслевом масштабе набор возможностей без риска ошибиться в прогнозе тенденций рынка. Поскольку вы работаете с хорошо известным и заслуживающим доверия заказчиком, риск при разработке ПО такого типа обычно связан с верной реализацией функций и своевременным завершением разработки, а не с применением инновационных технологий.

Ячейка 4. Тактика заключается в расширении функциональности продукта, который уже поставляют конкуренты. Риск в случае такого ПО должен быть относительно невелик, так как вы работаете в основном с хорошо известными функциями и технологиями на устоявшемся рынке. Поскольку риск столь мал, на тестирование удобства использования и последовательное улучшение прототипа уйдёт меньше времени, чем в других случаях.

Помните: задача – обеспечение желаемого коммерческого эффекта при реализации сформулированных вами требований. Хотя вполне можно создать набор требований, распределяющийся по ячейкам таблицы практически поровну, в общем случае это нежелательно, поскольку так можно легко отойти от намеченной цели. Намного лучше сосредоточить большинство требований в одной из ячеек, а остальные требования разместить ещё в одной-двух ячейках.

Определение приоритетов

Определив и проанализировав требования, вы вплотную приблизились к обладанию полным набором функциональности. Но, прежде чем идти дальше, нужно задать приоритеты требований. Это поможет заранее оценить важность каждого требования и понять, как они связаны с другими требованиями.

Почему это так важно

Расстановка приоритетов определяет планирование и распределение задач. Вообще при планировании стараются наметить окончание реализации наиболее критичных требований на максимально ранние сроки. Если сначала сконцентрировать усилия команды на воплощении самых важных требований, можно снизить неопределённый риск, неизбежно присутствующий в любом плане. После завершения реализации критичных функций новая программа уже будет жизнеспособной. Если на этом этапе придётся сжимать сроки или вносить непредвиденные изменения, то вы окажетесь в выигрышном положении и сможете быстро завершить работу над новым выпуском программы, так как её основные функции будут уже готовы.

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

Как это делается

Каждому требованию должен быть назначен тот или иной приоритет. Детализация приоритетов может быть любой, в зависимости от потребностей. Уровни приоритета можно определить следующим образом:

• Необходимые

Обязательно должны быть воплощены в программе, без этого её нельзя выпускать на рынок. Необходимые функции должны быть реализованы и испытаны как можно раньше; этому нужно уделить максимум внимания и все ресурсы.

• Желательные

Присутствие этих требований крайне желательно. При достаточном обосновании от их реализации можно отказаться, но это не уменьшает важности их наличия в программе. Реализация и испытания желательных требований начинается сразу после обязательных.

• Возможные

Эти требования также желательны, но реализуются в последнюю очередь и являются первыми кандидатурами на удаление, если вдруг возникнут проблемы со сроками.

Утверждение требований

Многие ошибочно считают, что сформулировав требования, они готовы к распределению заданий и планированию проекта. Это не так. Нужно выполнить ещё два важных действия: провести техническую экспертизу основных факторов риска, связанных с технологиями, и создать прототип пользовательского интерфейса вашей программы. См. об этом главы 9 и 10.

Представим на минуту, что прототип пользовательского интерфейса уже готов и технологическая экспертиза закончена. Готовы ли вы поставить свою подпись на списке требований? Ещё нет. Нельзя утверждать требования, пока не составлен план работы. Может оказаться, что на исполнение плана должно уйти слишком много времени, и придётся отказаться от реализации части требований. Если требования уже утверждены, то может оказаться, что при их реализации не удастся уложиться в заданные временные рамки. Не стоит утверждать требования поодиночке, пока не будет ясности с другими требованиями.

Управление внесением изменений

Разработка ПО – динамический процесс. Не важно, насколько всеохватывающими будут начальные требования – все равно по мере продвижения по циклу разработки придётся вносить изменения. Постоянно возникают неожиданные проблемы, рождаются идеи, меняются потребности рынка. Однако изменчивость требований – не самая большая проблема. Важнее организовать работу, чтобы поднимать эти проблемы для последующего решения, направлять процесс принятия решений и доводить результаты до сведения коллектива.

Вот ряд фундаментальных принципов, которые нужно учитывать:

• Создавайте команду в составе менеджера проекта и всех руководителей групп, которая будет рассматривать все вносимые изменения

Команда должна регулярно собираться, ответственно подходить к рассмотрению запросов на внесение изменений и гарантировать, что руководитель каждой группы может оценить эффект изменения. Менеджер проекта должен следить, чтобы рассмотрение запросов на внесение изменений шло эффективно, а рассматриваемые запросы не выходили за рамки компетенции команды. Он также должен изучать влияние изменений на план исполнения проекта. При внесении изменений нужно пересмотреть и соответствующим образом изменить план.

• Необходимо не только разрешить, но и стимулировать группы, ответственные за реализацию определённых функций, к улучшению этих функций ПО

Такая свобода поможет им быстрее пересматривать и улучшать продукт. Однако недопустимо, чтобы улучшения частных особенностей или более тонкая настройка негативно отражалась на исполнении проекта. Если изменение влияет на требования или на его внесение уйдёт больше времени, чем допускает план, при обработке запроса на внесение этого изменения нужно обязательно следовать вышеописанной процедуре.

Единственное исключение – обязательные требования. Они являются наиболее важными, и их нельзя изменять как таковые без оценки и санкций извне. От реализации этих функций зависит работа других подразделений компании, и их также необходимо включить в процесс принятия решения. Так, внешнюю экспертизу могут производить менеджеры по продукции, маркетингу, старшие менеджеры и другие ключевые заинтересованные лица.

• Необходимо ознакомить с изменениями всю команду

Эти сведения можно просто разослать по электронной почте или обговорить на очередном рабочем собрании – главное, чтобы в курсе изменений был каждый.

• Все изменения должны быть документированы

Документирование позволяет команде отслеживать и анализировать изменения в проекте. Следует указывать дату внесения изменения, его суть и краткое обоснование. Важно, чтобы на протяжении жизненного цикла выпуска ПО подобная информация хранилась в едином месте, чтобы все участники группы могли обращаться к ней по мере необходимости. Можно вести реестр изменений в начале документа со списком требований или регистрировать в специальном журнале все утверждённые запросы на внесение изменений.

Общие проблемы и решения

Далее обсуждается ряд типичных проблем и вопросов, возникающих при использовании описываемых здесь методик, а также их решения.

Как изыскать время

Одна из самых распространённых причин для отказа от формулирования требований (а также от затраты усилий на создание прототипов пользовательского интерфейса) в том, что на решение этих задач требуется время. Узнав, сколько времени уходит на это, некоторые спрашивают: а с пользой ли оно тратится? В начале проекта все находятся под давлением потребности поскорее выдать первые результаты, поэтому такой вопрос вполне закономерен.

Ответ однозначен: «Да». Некоторые подходы к разработке ПО подразумевают затрату значительного времени на анализ и вывод подробных формулировок требований. Но подход, рассматриваемый в этой главе (и в следующих двух) предлагает цикл определения требований – он экспериментально проверен и подтверждён положительными отзывами. Это не только не позволяет группе расслабиться, но и даёт возможность проявить творческий подход и поэкспериментировать, прежде чем черновики планов будут созданы и переданы на утверждение. Кроме того, использование прототипов пользовательского интерфейса и технических решений позволяет увидеть и почувствовать результаты работы над проектом.

Формулируйте сами задачи, а не способы их решения

Спецификация требования должна отвечать на вопрос «что должно быть сделано?», а не «как это сделать?». Ответ на вопрос «как?» проще всего получить с помощью анализа технической осуществимости и создания прототипа пользовательского интерфейса. К сожалению, часто формулировки требований включают описание способов их реализации, что может сузить выбор возможных решений. Вместо этого следует позволить команде задействовать свой творческий потенциал, чтобы генерировать множество возможных решений, а затем экспериментально проверить их в реальном мире.

Рассмотрим в качестве примера вышеупомянутое приложение для обработки заказов. Одно из ключевых требований таково: «Принимая заказ на товар, нужно собрать следующую информацию: X, Y и Z». Заметьте: требование содержит формулировку самой задачи, но не способа её решения. Можно привести пример требования с описанием способа его реализации: «Пользователь должен выбрать в меню пункт New|Create Order и ввести нужную информацию в диалоговом окне». Лучше позволить команде, ответственной за разработку пользовательского интерфейса, самостоятельно найти лучший способ реализации этого требования путём работы с прототипом.

Не упустите главное

В большинстве случаев участники проекта воспринимают формулирование требований в штыки именно из-за плохо налаженного управления требованиями. Проекты страдают из-за «размазанности» и неполноты требований, отсутствия приоритетов и из-за неуправляемых изменений. В этой главе мы сосредоточились лишь на главных вещах, необходимых для поддержания проекта в управляемом и предсказуемом состоянии, не перегружая группу обработкой второстепенной информации и бумажной работой. Не забывайте всё, о чём здесь говорилось, при работе над собственным проектом.

Глава 9
Исследования, оценка технологий и моделирование

В начале любого напряжённого проекта велико искушение принять решения о применении новых технологий, компонентов и платформ лишь на основе общих допущений. Производительность, масштабируемость и даже среду разработки и инструменты нередко оценивают и подбирают «на глазок». Если сделанные допущения верны, считайте себя большим героем, сэкономившим кучу времени. Но в случае ошибки проект с самого начала обречён.

Значит ли это, что любой проект – это лотерея? Да, во многом так оно и есть: не разобравшись в некоторых вопросах планирования, о которых пойдёт речь в этой главе, вы сильно рискуете. Иногда этот риск оправдан, но чаще – нет. Почему? Да потому, что в данном случае все против вас: чем больше вы делаете допущений, тем больше риск.

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

Чем полезны исследования и прототипы

Исследования, оценка и использование прототипов позволят ещё до начала работы над проектом понять все возможности и ограничения технологий, которые планируется применить. Если максимально задействовать эти подходы, то все перечисленное ниже станет намного легче.

• Упрвление рисками и создание рациональных планов

На ранних стадиях реализации проекта надо определить основные технологические проблемы и наметить пути их решения. Нерешённые технологические проблемы могут внести хаос в реализацию проекта. Фактически это одна из самых распространённых причин срыва планов. Не следует утверждать план или начинать работу над проектом, пока не решены основные технологические проблемы.

• Уверенность в успехе

Когда технологии, подходы и архитектура применяются впервые, мало кто из коллектива верит, что всё заработает. Это и понятно: в отсутствие опыта решения подобных проблем шансы на успех могут казаться призрачными. Однако такого рода сомнения могут стать источником реальных проблем. От недостатка уверенности в успехе проекта страдает не только боевой дух группы, но и производительность труда. Поэтому задача – как можно раньше исключить всякие сомнения и создать уверенность, что проект может быть и будет успешным.

• Прогноз проблем с производительностью

Почти всем ясно, что производительность приложений приобретает всё более важное значение. К сожалению, оптимизация производительности – это не та задача, которую можно отложить на потом, чтобы заняться ею в конце работы над проектом. Здесь нужен другой подход: следует заранее построить модель, воплощающую важнейшие черты архитектуры проекта, и как можно раньше протестировать её, чтобы выяснить, насколько хорошо она масштабируется.

• Прорывы в технологии

Чтобы работать на рынке с жёсткой конкуренцией необходимы исследования. Следует направить часть усилий группы на прогноз нужд потребителей, а также на поиск революционных решений и идей. Прекрасные идеи, новые подходы и хитовые приложения не появляются по волшебству в одночасье – их вынашивают как младенцев.

Исследования

Хоть некоторые и считают исследовательскую работу чисто академическим занятием, она тем не менее играет важную роль в разработке ПО. В этом разделе мы обсудим основы ведения исследований в приложении к созданию программных продуктов.

О чём пойдёт речь

Исследования бывают фундаментальные и прикладные. Первые – это процесс открытий и изобретений в надежде создать что-то полезное. Однако у результата такого исследования может и не быть коммерческого применения. С другой стороны, прикладное исследование на основе логических построений и анализа ситуации в некоторой отрасли ведёт поиск потенциально выгодных решений и пытается превратить гипотезы в конкретные идеи, которые помогут создать некоторый продукт.

Прикладные исследования – наиболее важная форма исследований в контексте этой книги. Они могут обеспечить критически важное преимущество в конкурентной борьбе, особенно на нестабильном рынке, когда потребности пользователей, ПО и аппаратные платформы и технологии претерпевают стремительные изменения. Хотя изменения часто вносят неопределённость, они также дают невероятные возможности группам, способным предвидеть потребности потребителей и задействовать новые технологии для их удовлетворения. Если, занимаясь созданием новой технологии, вы хотите «остаться на плаву» вопреки всем неожиданностям, то параллельно циклу разработки нужно вести непрерывную исследовательскую работу.

Из собственного опыта

Отладчик ядра 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, а мы уже обладали фундаментальной технологией для следующего выпуска программы.