Ключ к успеху лежит не в технологии программирования, а в выборе того, что не включать в первую версию вашего приложения. Я не сторонник запуска бета-кода, вовсе нет — выпуск бета-версии программного обеспечения, будь то открыто или под видом версии 1.0, непрофессионален, если вы намерены взимать плату со своих клиентов за эту привилегию. Нет, я предлагаю вам строго сократить набор функций до минимума, необходимого для выполнения намеченной работы. Должны оставаться только обязательные функции, а количество полезных функций должно увеличиваться до тех пор, пока вы не выясните, действительно ли они нужны вашим пользователям. Это позволяет достичь двух целей: вы раньше выводите на рынок стабильное приложение и можете увидеть, как люди используют ваше приложение в полевых условиях, прежде чем принимать решение о новых функциях. Я гарантирую одно: они не будут использовать его так, как вы ожидали!
Basecamp, приложение для планирования, о котором я упоминал ранее, было разработано компанией 37signals, мастером такого подхода. С помощью Basecamp цель 37signals заключалась в повышении эффективности разработки на основе проектов. Было решено, что основная причина, по которой проекты не выполняются в срок и бюджет, — это не отсутствие планирования, а плохая коммуникация, поэтому основное внимание Basecamp уделяется обмену информацией. полностью отличается от своего главного конкурента, Microsoft Project, знаменитого сложного приложения, которое позволяет планировать и контролировать проект от начала до заканчивать. Подход Basecamp подойдет не всем, но в реальном мире он смазывает колеса коммуникации как внутри компании, так и внутри компании. команда проекта и взаимодействие с клиентами — это самый важный вклад, который может внести Интернет, и Basecamp делает это великолепно.
Если вы хотите узнать больше о подходе 37signals, я рекомендую книгу «Getting Real: The». более разумный, быстрый и простой способ создать успешное веб-приложение, которое вы можете просмотреть в Интернете. бесплатно ( http://gettingreal.37signals.com), но я бы посоветовал выложить 25 долларов (12,32 фунта стерлингов) за печатную версию: это всего лишь пара сотен страниц, но оно того стоит. Для меня это подтверждает взгляды, к которым я пришел за долгое время, о неэффективности разработки программных проектов.
д.конструкт 07
Кстати говоря, через неделю после того, как я прочитал книгу 37signals, я посетил d.construct 07, конференцию по веб-дизайну и разработке, которая проводится каждый год в Брайтоне. Темой этого года был пользовательский опыт, и поскольку я больше разработчик, чем дизайнер, я не был полностью уверен, что мне это понравится. Мои опасения развеялись после увлекательного первого занятия с экспертом по юзабилити Джаредом Спулом, но самым полезным был доклад Лейзы Райхельт о процессах разработки.
Самый распространенный способ разработки веб-приложения (или любого другого приложения) использует подход «водопад», который обычно состоит из четырех этапов: масштаб, проектирование, программирование и развертывание (их фактические названия могут варьироваться в зависимости от организации). На первый взгляд такой подход кажется логичным — сначала детально опишите приложение, затем передайте эту спецификацию команде разработчиков; они создают внешний вид, который затем передается программистам, которые пишут код для реализации этого проекта, и, наконец, доставляют этот код в реальный мир.
Проблема в том, что эта схема зачастую мало похожа на то, что происходит на самом деле. По моему опыту, на этап спецификации уходит слишком много времени, что приводит к сокращению времени, доступного для программирования, но это не единственная проблема. Дело в том, что заранее подробно описать большое и сложное веб-приложение практически невозможно — для этого потребуются сверхчеловеческие способности, чтобы визуализировать конечные результаты в таких деталях. Большинство поставляемых продуктов существенно отличаются от своих первоначальных спецификаций, а те, которые этого не делают, часто от этого становятся хуже.
