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