Судя по оптимистичному тону профессора Сяовэя Чжуана (Xiaowei Zhuang), уверенного в возможности ускорения процедуры STORM-микроскопии вплоть до исследования живых клеток с молекулярным разрешением в реальном масштабе времени, разработчики надеются преодолеть это концептуальное противоречие. Но, может быть, ближе к истине профессор Дженнифер Липпинкотт-Шварц (Jennifer Lippincott-Schwartz), видящая будущее новых методик в их сочетании с электронной микроскопией: «Соотнося результаты PALM-микроскопии с электронномикроскопической картиной, можно понять, как отдельные активные молекулы распределены по тонким субклеточным структурам».
МЫСЛИ: Жизнь технического задания
Автор: Олег Бунин
Этой статьей я не хочу доказать, что написание технического задания - зло и корень всех бед, нет, ни в коем случае. Все и всегда относительно, а в нашем случае - зависит от задачи. Я хочу показать, что классические схемы разработки программного обеспечения работают не всегда, не всегда эффективны, часто приводят к ненужным конфликтам между менеджерами и исполнителями. Особенно это касается разработки веб-приложений. Я расскажу об экстремальном программировании, но не так, как пишут в книжках, а исходя из реалий - из того, что попробовали команды под моим руководством. О тех методиках, которые работают.
Изменчивый мир
Когда я слышу о техническом задании на разработку веб-сайта, я внутренне улыбаюсь - еще один продукт, устаревший уже в момент выхода. Это первая проблема всех технических заданий - предположение, что внешняя среда не меняется.
Вторая проблема хорошо известна и отражена в древней мудрости: чтобы задать правильный вопрос, надо знать половину ответа. В ситуации, когда каждый новый сайт вы разрабатываете с использованием только что появившихся технологий (новые модули, новая версия собственного движка, новая версия базы данных), - фактически вы каждый раз многое делаете заново. Это значительно осложняет процесс разработки, потому что вы не знаете, как будете это разрабатывать.
Третья проблема классическая - заказчик не всегда точно знает, чего он хочет. И когда подходит срок сдачи проекта, вы слышите, что вот здесь хорошо бы подправить, вот здесь изменить, а вот здесь добавить. Частично эту проблему решает моделирование конечного продукта, но, повторюсь, лишь частично.
Выпуск конкурентами нового продукта, появление нового брэнда, новой технологии, нового браузера, изменение предпочтений потребителей - все это требует немедленной реакции, изменяет предметную область, описанную в ТЗ. Заказчик увидел сайт конкурирующей компании и хочет такую же «штуку». При этом вы не знаете заранее, как будете реагировать и сколько времени потребует реализация той или иной вашей реакции. Одним словом - хаос…
