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

Новости

• Вышло обновление DEVPROM, в этой версии мы добавили ряд долгожданных возможностей, таких как подписка на обновления (watching) и создание пожеланий по email, а так же несколько новых фич в Enterprise версию системы, подробнее...
• Для живой демонстрации возможностей DEVPROM мы подготовили несколько проектов, расположенных по адресу http://demo.pmcloud.ru вы также можете создавать свои проекты и оценивать возможности enterprise версии системы.
• Напоминаем, что есть такой вариант использования DEVPROM как Enterprise Edition SaaS - очень дешевый способ обзавестись собственным экземпляром DEVPROM без каких-либо ограничений, включающим Enterprise фичи и Subversion-репозиторий, без необходимости где-то искать хостинг, что-то устанавливать и администрировать. Просто напишите нам.

Публикации

• Примерно год назад мы открыли для себя mindmaps в качестве очень удобного дополнительного инструмента в работе над проектами. Хочется рассказать про два кейса, которые мы наиболее часто применяем в работе, на примере проекта построения достаточно большого хранилища данных. Подробнее: Примеры использования MindMaps в проектной работе
• Специалисты, задействованные в разработке программного обеспечения, являются довольно дорогостоящим ресурсом, а проекты, в которых они участвуют сильно отличаются друг от друга по плотности задач. Из-за этого часто одни и те же люди участвуют в одновременно в нескольких проектах, например, в новом и предыдущем (с целью его поддержки), либо выделяются на некоторый процент времени в случае с матричной системой управления проектами. Подробнее: Анализ загрузки ресурсов
• Система управления проектами DEVPROM позволяет разработчикам ПО готовить справочную документацию к программным продуктам без использования дополнительных инструментов, например, Author-It или RoboHelp, предоставляя следующие ключевые возможности. Подробнее: Создание справочной документации к продукту
• В компаниях и распределенных командах, занимающихся разработкой программного обеспечения, часто возникают рутинные задачи по организации и обеспечению поддержки процесса разработки, которыми кому-то нужно заниматься, но нет возможности это делать в те моменты, когда это нужно. Вот только небольшой список подобных задач. Подробнее: Поддержка проектных команд
• При работе над проектом, особенно, если не все члены команды размещаются в одной комнате, просто необходимо получать свежую информацию об изменениях в проекте (нотификаций), например, при помощи уведомлений по электронной почте, через RSS-канал или другими способами. В DEVPROM существует несколько вариантов нотификаций. Подробнее: Возможные варианты нотификаций
• В последнее время различные методологи все чаще обращаются к вопросу качества разрабатываемых продуктов, при этом не прибегая к использованию сложных и долгих формальных методов верификации, поскольку современные практики разработки ПО позволяют дать дешевый и достойный ответ. Подробнее: Раннее тестирование (early testing)
• Поддержка разработанных или еще разрабатываемых программных продуктов часто применяется при заказной или продуктовой разработке, причем, из-за размеров и количества частей, составляющих программный продукт, в этот процесс могут быть вовлечены отдел поддержки и несколько проектных команд, разработавших свои части продукта. Подробнее: Организация поддержки продуктов
• Любую крупную задачу, а именно такой и является разработка программного продукта, эффективно разбить на множество небольших, относительно независимых подзадач. Именно данный принцип позволяет измерять прогресс выполнения исходной задачи, вычислять текущий статус проекта. В зависимости от количества участников проекта, сроков его завершения, уровня зрелости команды, финансовой модели, по которой выполняется проект, необходимо применять соответствующие методики измерения хода проекта. Подробнее: Варианты оценки производительности команды
• По сравнению с вовлечением пользователя в процесс разработки или предоставления пользователям портала проектов, вариант с почтовым ящиком, конечно существенно проигрывает, однако, из-за различного рода ограничений все же остается востребованным вариантом. Подробнее: Поддержка продуктов по email
• Если вы чувствовали недостаток обмена информацией между проектами, то в корпоративной версии DEVPROM мы постарались решить эту проблему. Что за проблема и откуда она взялась? Попробую пояснить. Подробнее: Объединение данных из нескольких проектов

С уважением, команда DEVPROM.

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

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

Для системы управления проектами DEVPROM появилась подобная функциональность, которая позволяет реализовать этот вариант взаимодействия с пользователями:

1. Вам необходимо выделить почтовый ящик для приема сообщений от пользователей.
2. В разделе администрирования DEVPROM, на закладке "Обработка почты" необходимо добавить почтовый ящик и указать параметры подключения к почтовому серверу.
3. Необходимо сопоставить почтовый ящик проекту, в котором будут создаваться пожелания на основе сообщений, находящихся в этом почтовом ящике.

Данная функциональность состоит из следующих моментов:

• Периодический мониторинг почтового ящика, создание пожеланий на основе сообщений, появляющихся в почтовом ящике, удаление обработанных сообщений.
• Прикрепление к созданным пожеланиям приложений из сообщения.
• Подписка авторов исходных сообщений на изменения и обсуждения (добавление комментариев) пожеланий, которые были созданы на основе этих сообщений.
• Отслеживание обсуждений с одинаковой темой, при этом новые сообщения с темой, по которой уже было создано пожелание, добавляются к пожеланию в форме комментариев.

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

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

Трудно не согласиться с тем, что обратная связь является одним из ключевых моментов гибкой (да и не только гибкой) разработки, отчасти именно поэтому работа и ведется короткими итерациями.

Но обычно, когда говорят об обратной связи, имеется ввиду связь Заказчик-Команда разработки, то есть заказчик все время корректирует наше движение вперед.

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

Более того, мы должны не просто позволять завести идею или ошибку через малозаметную ссылку на форму обратной связи на сайте, мы должны поощрять пользователей участвовать в развитии нашего продукта, ведь именно они (пользователи) приносят нам деньги, пользуясь нашими продуктами. Больше довольных пользователей = больше денег.

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

Я уже как-то писал о том, что невероятно здорово, с точки зрения обычного пользователя, работать с продуктом, разработка которого ведется высокоитеративно и открыто. Пользователи, на основе доступного им публичного плана итераций, могут формировать свои ожидания относительно реализации необходимых им фич или исправления дефектов. Лично я это очень ценю, и каждый раз вспоминаю GreenHopper, как первый подобный продукт с которым мне довелось работать.

На мой взгляд, для адекватной формы обратной связи нужно:

• сделать ее максимально доступной пользователю, а не маленькой ссылкой внизу страницы
• помещать заведенные пользователями пожелания в журнал (User Backlog?), к которому обязательно давать доступ пользователям
• подписывать пользователя по email на все действия с его пожеланием (запланировано на итерацию, реализовано, отложено и т.п.)
• иметь возможность комментировать пожелание для общения пользователя и команды, с отправкой уведомлений по email
• обеспечить возможность пользователям голосовать за пожелания (рейтинговать), чтобы влиять на их включение в следующий релиз продукта
• в идеале, буквально нажатием одной кнопки пожелания пользователей должны попадать в бэклог команды разработки и далее планироваться на итерацию, т.е. форма обратной связи должна быть интегрирована с инструментом ведения проекта.

Звучит заманчиво?

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

Форма встраивается на сайт несколькими строками html кода, цвета, размер и шрифты настраиваются.

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

Вот так примерно, на мой взгляд, должна выглядеть хорошая форма обратной связи с пользователями. Я бы очень хотел видеть такую на большинстве сервисов, которыми мне приходится пользоваться ежедневно.

Вы как думаете?