На прошлой неделе состоялась конференция «Российские интернет-технологии», на которой мы рассказывали о практике написания ТЗ, которую мы успешно применяем на наших проектах.

Большинство систем, которые мы разрабатываем, связаны с вебом. Одной из отличительных особенностей веб проектов является их скоротечность. Цикл разработки большинства систем составляет от трех месяцев до полугода. Этому способствует несколько обстоятельств:

  1. Динамичная среда — интернет очень быстро меняется, постоянно появляются новые технологии, и то, что было популярным и модным несколько месяцев назад, сегодня уже не так актуально.
  2. Конкурентный рынок — в битве за аудиторию важно выйти на рынок как можно раньше, опередив конкурентов.
  3. Основной источник информации пользователи — практика показывает, что даже детальная проработка ТЗ, включая создание пользовательских групп, предварительное тестирование и т.п., не так полезна, как обратная связь от пользователей, которая может быть получена только после выхода первой версии системы. К тому же на полноценное исследование, как правило, нет времени (см. пункты 1,2)

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

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

По нашем мнению, у традиционных, «бумажных», ТЗ есть две основные проблемы:

  1. «Слишком много букв». Заказчики неохотно читают большие документы. Конечно, отчасти это вопрос их заинтересованности в результате, но, тем не менее, такая проблема реальна.
  2. Словесное описание интерфейса по-разному интерпретируется участниками процесса. Это самая большая проблема. Поскольку в веб системах значительную часть составляет пользовательский интерфейс (который, к слову, может быть весьма сложным и навороченным), основная задача этого документа — сформировать в головах заказчика и разработчиков одинаковое представление о том, как должна выглядеть система. К сожалению, словесное описание оставляет слишком большой простор для фантазии, поэтому результат в 99% случаев не соответствует представлению.


001

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

Например, такие:

002

Это позволяет решить следующие проблемы:

  1. Сокращается объем ТЗ. Его гораздо легче читать, поддерживать в актуальном состоянии и отслеживать изменения.

  2. У участников проекта формируется одинаковое представление о том, как будет выглядеть система. Какие функциональные элементы будут на том или ином экране, как они будут реализованы.

На рынке существует достаточно большое число инструментов, которые позволяют рисовать пользовательские экраны, не будучи профессиональным проектировщиком интерфейсов. В результате экспериментов, мы остановились на продукте Balsamiq, который успешно используем.

Полную презентацию доклада можно посмотреть на Slideshare.net

У нас есть заказчики и партнеры в разных странах, и порой не все они могут комфортно изъясняться на английском языке. Мы в нашей работе используем trac для багтрекинга и документации. И поэтому мы написали и поддерживаем плагин для trac-а, который использует Google Translate и переводит тикеты и комментарии пользователей на язык, указанный в настройках пользователя.

Перевести
Перевод

Всем, кто сталкивается с подобными задачами, рекомендуем.

Страница плагина.

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

Начнем с того, что медиа-информацию (видео и аудио) необходимо хранить в цифровом виде, и хорошо бы еще и в сжатом. Этим занимаются кодеки (codec, coder-decoder). Они переводят медиа-информацию в цифровой поток и обратно.

codecs
Читать дальше »

Вступление

Тернист и извилист путь Java-платформы к правильному способу записи строчек в лог-файлы. История logging в Java довольно познавательна в плане изучения особенностей Open Source, в том числе его взаимодействия с корпорациями и единичными программистами. Я собираюсь рассказать столько, сколько возможно, об истории развития Java logging, а также о том, к чему все пришло и как жить дальше. Читать дальше »

Как было сказано ранее, во второй части статьи речь пойдет о типовых приемах написания приложений для android. Однако, вначале несколько слов о Java API, имеющимся в распоряжении разработчика. Читать дальше »

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

Платформа Android — это основанная на ядре Linux адаптированная для работы на смартфонах система. Java — это основной язык для разработки приложений на этой платформе. Читать дальше »

Вторая часть обзора посвящена среде Google AppEngine.

В отличии от GWT, который является просто средством разработки, одним из ряда аналогичных, на GAE нужно посмотреть и с другой стороны. GAE это не просто среда (платформа), где выполняются приложения (кстати, совсем не обязательно, написанные на GWT), но и хостинг. Читать дальше »

Данный обзор ставит целью помочь руководителям проектов и программистам, не знакомым с технологиями Google Web Toolkit и Google App Engine, принять правильное решение об использовании или неиспользовании их в новом проекте.

Читать дальше »

AJAX и все, все, все

В предыдущей серии мы делали простенькое Grails-приложение с использованием jQuery, а также решили для себя, что использовать jQuery в Grails можно и даже нужно. Обсудим более серьезные вещи, которые можно сделать с такой связкой.

Нетрудно заметить, что все больше сайтов используют AJAX и частичные обновления страниц, причем в невероятном количестве. В частности, «начиненные» AJAX ссылки могут использоваться для внутренней навигации по странице, переключения каких-то вкладок. Это хорошо тем, что
А) меньше данных нужно перегонять от сервера — только нужный кусок страницы и
Б) веб-страницы часто загружают просто гигантские CSS и JavaScript-файлы, которые при AJAX-обновлении можно повторно не загружать.

Итак, очень распространено построение приложений по сценарию: одна большая «стартовая» страница, загружающая весь JavaScript-код и CSS и более мелкие «внутренние» функциональные блоки, загружаемые через AJAX. С этим есть ряд проблем:

  1. В результате AJAX-действий внутреннее состояние страницы не отражено в адресной строке браузера.
  2. Как следствие, внутренние страницы не могут быть запомнены в закладки, нельзя «отправить ссылку другу».
  3. Не работает Back/Forward навигация в браузере, т.к. AJAX-ссылки не попадают в историю браузера.

Однако крупные сайты нашли некое «хакерское» решение, которое мы сейчас рассмотрим и напишем небольшой свой собственный аналог на Grails и jQuery. Читать дальше »

В данном посте хотелось бы просуммировать наш опыт работы над крупными интернет-проектами и рассмотреть характер и объем работ системной и инфраструкторной поддержки проектов.

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

Диаграмма объема инфраструктурных и системных работ

Читать дальше »

  • Sharing

    Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather