Главная Услуги Работы Персона Юзабилити анализы
IMG тел. +7(901) 370-1796
Деление по функциональности




ПОИСК по сайту


    Полный список статей
/ Деление по функциональности / Версия для печати / translit / абракадабра :-)


<-предыдущая следующая ->

 
  google.com bobrdobr.ru del.icio.us technorati.com linkstore.ru news2.ru rumarkz.ru memori.ru moemesto.ru smi2.ru twitter.com Яндекс закладки text20.ru RuSpace RuSpace toodoo

Тему про особенности итерационной разработки я со временем собирался продолжить. Во-первых, мы в компании выстраиваем гибкий процесс ведения проектов — и я позже напишу об общей сути этого процесса. Во-вторых, в ходе текущей работы решаются множество рабочих моментов, которые обусловлены итеративностью. Ну а недавно появилось и в-третих — плотная дискуссия по поводу последнего материала блога о проектировании системы управления проектами PMC. Которая как раз запускалась в несколько очередей. А многие авторы комментариев забыли о контексте их запуска.

Деление по функциональности

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

Тут важно избежать путаницы в терминах. В гибких методиках разработки итерациями зовутся не те этапы работ, по окончанию которых получается альфа-, бета- или другая версия системы. Это отрезки времени в одну или несколько недель (выбор длительности — исходя из особенностей проекта и организации компании-разработчика). Все это из-за того что писать по-настоящему подробное техническое задание на более-менее крупную систему слишком долго и затратно. Да и невозможно без дополнительных исследований — не все требования можно оценить, пока не попробуешь их реализовать. А календарные планы из сотен связанных между собой задач быстро забываются — скоро становится ясно, что отношения к реальности они имеют мало. Поэтому трудоемкость требований оценивается насколько это возможно точно, а последовательность их выполнения определяется по на основе приоритетности и важности для завершения текущих задач. Для каждой итерации выбирается для реализации столько требований, сколько возможно реализовать имеющимися ресурсами.

Для примера возьму тот же Project Management Center. В проекте были такие ключевые куски работ:

  1. Разработка платформы для нового поколения системы. Основные задачи:
    • Создать новую платформу;
    • Запустить ее как можно быстрее;
    • Обеспечить в первой версии работу наиболее важных для процесса работы компании функций;
  2. Доработка второстепенной функциональности. Основные задачи:
    • Добавить нереализованные функции из прошлого поколения системы;
    • Добавить новые для системы функций;
    • Собрать отзывы пользователей об использовании бета-версии новой системы и “отшлифовать” ее;
  3. Повышение эффективности работы с системой. Основные задачи:
    • Провести повторный анализ пользователей и их задач;
    • Доработать интерфейс для того чтобы поднять эффективность работы пользователей;
    • Создать упрощенные интерфейсы для выполнения повседневных и типовых задач;

Получается как раз публичная бета, продукт и продукт в стадии развития. Мы также можем выбирать основные точки приложения усилий. Это те функции и процессы, хорошая работа пользователей с которыми даст лучшее впечатление о новой версии системы. То есть что и в какую фазу включать. Причем самой тяжеловесной является первая — до ее окончания работать с продуктом нельзя (в случае с PMC это было 8 месяцев). А вот результаты по остальным фазам появляются по ходу завершения отдельных кусков работ.

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

Но это общий случай — несмотря на то что для PMC я описывал 4 группы пользователей, все они в одной лодке — участвуют в одном процессе. Кроме того, система обязательна к использованию и можно ожидать понимания пользователями того, что в первом старте не все гладко.

Деление по целевой аудитории

Более гибкое разбиение на этапы можно сделать, если пользователи системы имеют мало пересекающиеся цели и “заходят” к ней с разных сторон. Тут отличным примером будет один из наших текущих проектов, закрытая бета-версия которого была запущена на днях. Сам продукт (если очень грубо — новостной сайт) предназначен для трех групп пользователей:

  1. Потребители. Обычные пользователи, которым важна полнота и удобство сервисов. Им нужен конечный продукт, две ключевые составляющие которого — функциональность и контент — в сумме намного лучше, чем у конкурентов. Если этого не будет — и первое, и остальные впечатления будет испорчены.
  2. Редакция. Команда поддержки продукта, которая наполняет его ценным для потребителя контентом. В первую очередь им нужна возможность наполнения системы информацией. Затем — формировать на основе имеющегося контента информационную картину дня.
  3. Заказчик. Заинтересованные лица, которым важна успешность и прибыльность продукта. Для них важны те же составляющие, что и для потребителя. Разве что сырой версии они не испугаются, если работы над системой не отстают от графика.

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

  1. Приемка заказчиком. Проходит в два этапа:
    1. отдается закрытая бета с ключевой функциональностью;
    2. сдается весь продукт.
  2. Вовлеченность редакции. Каждый из этапов приемки заказчиком разбивается на несколько частей. Чем дальше, тем меньше требуется участия команды разработки:
    1. сперва редакция просто смотрит, все ли учтено в базовой функциональности для потребителя. Для них важно, смогут ли они создавать весь этот контент;
    2. затем — получает редакторский интерфейс, после чего он совместными усилиями улучшается и начинается наполнение системы контентом;
    3. через месяц-полтора общий процесс отлажен и начинается новый этап — выстраивание редакционной политики;
    4. последним шагом идет полноценный рабочий режим, до запуска незаметный потребителю — это нужно для финальной отработки редакционного процесса.
  3. Внутренний процесс разработки. Двухнедельные итерации, по итогу каждой из которых продукт получает новый набор функций и качеств. Нужны для более гибкого планирования и большей эффективности работы команды. Это тема для отдельного материала, но Юрий Шиляев недавно писал об этом процессе для этого же проекта у себя.

Имея понимание, для кого и что мы делаем, становится легче прилагать усилия в конкретных местах. Это как чек-пойнты в гонках — во-первых, понятно направление движения. Во-вторых, сохраняется хороший темп — к каждой из контрольных точек нужно прийти с приемлемым результатом. Ну и в-третьих, всегда есть законченный результат работ по одному или нескольким пунктам — будь то функциональность или качества продукта. А это и команде разработки приятно вдвойне — сразу видно, на что потрачены усилия.

Кроме того, хорошо обоснованное разбиение на этапы помогает решать конфликты интересов. Я недавно писал об уставе проекта — в нем описаны не только сами этапы, но и общие задачи и цели проекта. Еще важнее не забыть о качествах системы, которые важны для ее успеха. Это помогает объяснить, почему, например, сейчас мы не особо занимаемся внешним видом системы. И рассказать, когда мы возьмемся за эту задачу. Цели, задачи и необходимые качества помогают понять, какие приоритеты у всего проекта и какие — у его отдельных этапов. Так легче найти общий язык и с заказчиком, и с командой разработки.

взято с http://www.jvetrau.com/2007/11/29/iteratsionnaya-razrabotka-razbienie-proekta-na-etapyi-ishodya-iz-konteksta-ispolzovaniya-sistemyi/


Создание эксклюзивных сайтов, юзибилити анализ и бесплатный анализ под запросы основных поисковых машин
Контактная информация :
тел. +7(901) 370-1796

Написать письмо на e-mail
icq 415547094  romverрейтинг на mail.ru сайта romverinbox.ru
© 1997 - 2017 romver.ru

Полная карта сайта Display Pagerank  
CMS version 3.6.3 | PTG 0,0217 s.