Для начала смоделируем ситуацию: вы заказываете разработку сложного мобильного приложения для своего бизнеса. После согласования основных деталей по бюджету, дизайну и обсуждения технических требований, команда приступает к разработке проекта: трудится над программной частью и доводит до совершенства дизайн, придумывает множество убойных фишек и, конечно, проводит тестирование на каждом этапе.
И вот наступает день Х – презентация готового продукта. Но долгожданный релиз выглядит совершенно иначе, чем вы ожидали! Возникает резонный вопрос: как это могло произойти, если все шло строго по утвержденной схеме и требованиям?
Это довольно распространенная ситуация в большинстве компаний по разработке ПО. Одним из успешных решений ее может стать демонстрация проекта, которая нашла отличное применение на практике и в нашей компании.
Анастасия Поветкина Менеджер проектов Inostudio
Что такое демонстрация?
Демонстрация проекта, или demo – это неотъемлемая часть любой работы над проектом, проводится по завершении спринта и нацелена на представление итогов работы клиенту. Как правило, demo позволяет определить, в правильном ли направлении движется проект, сформировать единое видение конечного продукта, следить за прогрессом и корректировать сложности еще в процессе разработки, а не на этапе сдачи проекта.
Что такое DEMO айфоны и что в них плохого?
Конечная цель demo – получение не просто проекта, соответствующего заявленным техническим требованиям, а действительно нужного именно вам и вашему бизнесу продукта.
Какая бы методология ведения проектов ни была выбрана (PMI, Scrum, Canban и т. д.), demo рекомендуется проводить на каждом из этапов работы над проектом:
- На этапе планирования, путем создания макетов и прототипов;
- На этапе разработки, демонстрируя промежуточные результаты, например, по завершении спринта или контрольной точки;
- По завершении всей работы, например, на последнем тестировании.
Я как менеджер проектов стараюсь показывать результат работ своим клиентам настолько часто, насколько это возможно.
Представим, что есть в наличии тестовый вариант мобильного приложения, планы работ на следующий спринт, результаты работ по завершении текущего спринта, клиенту отправлены уведомления о возможности начала тестирования новой версии продукта. Все это не дает гарантии, что все заинтересованные лица самостоятельно проверят результат.
Рассмотрим два кейса, которые встречались в практике
Кейс 1. Я информирую клиента о результатах спринтов, команда ведет все задачи в Trello или Jira, где весь процесс разработки можно отследить. Проходит десять спринтов, и по результатам очередных переговоров мы начинаем понимать, что клиент не знает своего продукта и не ориентируется в нем.
Кейс 2. Команда выполнила работы по спринту, протестировала новую версию продукта, внесла дополнительные изменения, я проинформировала клиента о том, чтобы он посмотрел результат. Пришел фидбэк, в котором сказано, что можно запускать проект. Все запустили, загрузили, и приходит еще одно письмо – что логика работы не такая, как ожидалась.
Трейдеру тоже Нужен Тренажер | Демо-счет для Практики
И знаете, какой вывод я вынесла из этого?
Демонстрация проекта должна быть показана клиенту, тогда подобных ситуаций не возникнет.
Команда разработала новый функционал вашего будущего бизнес-инструмента, менеджер проектов показал, описал и проговорил его вместе с вами. Таким образом, команда исполнителей лучше поймет, насколько результат удовлетворяет ваши ожидания, будем ли мы двигаться в заданном направлении или пора что-то изменить, пока еще не поздно…
Вернемся на секунду к разработке мобильного приложения: если бы на этапах работы над проектом были проведены demo, тогда вы бы получили замечательный продукт, и в день Х вас бы не ожидало разочарование. Аналогично и с кейсами: здесь проблема кроется в самом проведении демонстрации.
Важен не только факт проведения demo, но и способы презентации.
Конечно, личные встречи клиента с менеджером проектов – это идеальное решение, но чаще всего клиент и команда исполнителей далеки друг от друга. Поэтому есть иные способы проведения demo, которые я использую в своих проектах:
| Способы проведения демонстраций | Технология mobile/web | Описание и достоинства | Недостатки |
| Skype | web | Есть возможность демонстрации своего экрана (Звонки-Демонстрация экрана), инструмент позволит вам проговорить голосом изменения или функционал и показать его | Должен быть установлен у всех заинтересованных лиц, требуется Интернет-соединение. |
| Вебинар | web | Есть возможность демонстрировать свой экран/видео, есть возможность задавать вопросы в чате. Большое количество сервисов, например, Webinar.ru, GoToMeeting и др. | Требуется регистрация, некоторые сервисы платные, требуется Интернет-соединение. |
| Запись и отправка видео с экранов компьютера | web | Можно полностью показать функциональность и рассказать о ней. Из программ рекомендую использовать Monosnap, Snagit 12, Bandicam, Fraps и др. | Некоторые программы для записи с экранов платные. Обсуждения с заказчиком происходит не в режиме реального времени. |
| Запись видео с экранов телефонов | mobile | Для устройств Apple запись видео с экрана с помощью приложения quicktime player или других приложений с air play технологией. Для Android платформы самые распространенные приложения scr, rec.free и др. | Некоторые программы для записи с экранов платные. Обсуждения с заказчиком не в режиме реального времени. Не везде можно записать голосовые комментарии. |
| Сервисы для отгрузки тестовых приложений на мобильные устройства | mobile | Для мобильных устройств Apple мы используем testflight. Для Android платформ можно использовать fabric. Клиент может скачать тестовую версию приложения на свое устройство и проверить его работу. | Требуется интернет соединение и настройка сервисов. Клиент может посмотреть и проверить не все, что было сделано. |
Подведем итоги
- Я настоятельно рекомендую как можно чаще проводить demo.
- Идеальным вариантом является проведение демонстрации проекта после каждого спринта, чтобы вы могли увидеть, пощупать и протестировать полученный на данном этапе продукт, оценить его функционал, дать напутствия команде разработчиков и обсудить возможные разногласия, вопросы и новые идеи.
- Проведение demo нацелено на создание первоклассного бизнес-решения, которым вы будете довольны на все 100%, и даже больше.
Источник: rb.ru
Среды разработки или что такое dev, demo, stage и prod
После перехода в мир IT и активной работы там мне стали чаще попадаться термины, которые поначалу казались непонятными. Коллеги вокруг привыкли излагать мысли привычными им словами, потому иногда в меня бросали следующими фразами «Зайди на прод» или «Нужно задеплоить стейдж». Теперь такие слова мне не кажутся чем-то непонятным, так как пришло некоторое понимание. Хочу поделиться им с новичками и всеми желающими, кто тоже слышал все эти проды, девы и стейджы, но не понимал о чем речь.
Мое объяснение не претендует на точное соответствие имеющейся теории разработке ПО, я пытаюсь объяснить так, как понимаю и как мне кажется, будет понятнее другим.
Среды разработки
Любой процесс производства чего-либо состоит из определенных этапов. В разработке программного обеспечения (туда же отнесем и сервисы) тоже существуют свои этапы, которые нужно соблюдать, чтобы достичь поставленных целей. Такими этапами являются:
- разработка
- сборка
- тестирование
- доставка конечному пользователю
DEV-среда
Место, где осуществляется разработка чего-либо. Там всегда самая свежая версия кода и продукта. Все новые идеи реализуются в первую очередь там и из разряда «давайте-ка сделаем…» переходят в конкретные строки кода.
DEMO-среда
Здесь хранится промежуточный результат, который можно «потрогать руками» и посмотреть так ли все работает, как должно. Если имеется заказчик, то он «трогает» и высказывает свое мнение насчет изменений. В это время на dev-сервере может уже по сто раз все изменится и поломаться.
TEST-среда
Продукт проверяется на стабильность путем моделирования нештатных ситуаций или использования нестандартных данных. По сути, это испытательный полигон, на котором можно делать все, вплоть до полного уничтожения всего и вся (на самом деле, нет).
STAGE-среда
Ее еще называют предпродакшн. Здесь используются данные из последнего бэкапа системы на prod-сервере, чтобы максимально проверить работоспособность и стабильность приложения или сервиса. Эта среда максимально приближена к тому, что видят перед собой конечные пользователи.
PROD-среда
Продакшн, если раскрыть слово prod. Это то с чем взаимодействуют пользователи. Если вы заходите на сайт, в приложение или игру, то взаимодействуете с тем, что опубликовано на prod-сервере. В этот же момент новый функционал во всю может разрабатываться и тестироваться на предыдущих средах.
Простой пример
Допустим вы разработчик многопользовательской игры. Если подходить к этому правильно, то у вас должен быть сервер, где все непосредственно разрабатывается (dev), сервер, куда имеют доступ тестировщики (demo), сервер, где игра проходит проверки на случай непредвиденных обстоятельств (test), сервер, куда вы пускаете некое количество живых игроков, чтобы они проверили обновление игры перед окончательным выходом (stage), сервер, куда, в случае успеха, выйдет обновление проекта (prod).
Например, в War Thunder или DayZ есть возможность тестировать обновления до их официального выхода. Таких игроков разработчики предупреждают о возможных ошибках и просят давать фидбэк, если такие возникнут.
Надеюсь, что у меня получилось объяснить главное и сделать это максимально просто. Если среди подписчиков или читателей есть опытные разработчики, то можете подправить или дополнить текст поста в комментариях. Ну и напоследок традиционный призыв к лайкам, комментированию и подпискам!
Источник: dzen.ru
Как провести демо клиенту
Зачем нам вообще проводить демо? В чем профит? Есть же дизайны, детально расписанные юзер стори или ТЗ, критерии приёмки. В конце концов, есть люди с зарплатой, которые проверяют, соответствует ли разработанное нами требованиям заказчика. Ответ — в ценности демо как для нас, как исполнителей, так и для наших клиентов: Ценность для клиента.
Демо даёт клиенту возможность потрогать продукт ещё на этапе разработки и скорректировать курс этой самой разработки — пересмотреть юзер стори, пофиксить что-то, добавить или наоборот убрать. Ценность для разработчика.
Для нас основная ценность демо прежде всего в получении фидбэка «из первых рук», и, чего уж таить, в обретении огромной уверенности (иногда ложной) в том, что мы на правильном пути. Есть множество практик проведения демо. Некоторые очень распространены. Другие используются довольно редко.
Демо — это вообще весьма индивидуальный процесс для каждой команды (особенно при отсутствии прописанной политики проведения демо). Я расскажу о нашем опыте. Что-то в нём универсально и подойдёт многим командам. Что-то — очень специфично и применимо далеко не всегда. Просто берите на вооружение то, что кажется вам полезным, а остальное смело пропускайте.
Итак, мы условно разделяем клиентское демо на два основных этапа — подготовка и собственно сам «экшон».
Подготовка к демо
Есть довольно простой постулат о тяжести в учении и лёгкости на работе. Можно его переформулировать в тяжесть подготовки и лёгкость проведения демо. Серьёзно, если потратить на подготовку достаточно времени, можно сильно облегчить себе задачу на непосредственной демонстрации. Вот, как к демо готовимся мы:
Пишем сценарий или демо-документ
Прежде всего стоит крепко задуматься о том, что именно показать клиенту на демо. Тут хорошим помощником будет заранее сформированный роадмап с дедлайнами. Опираясь на него, можно просто показать те компоненты, чьё время для появления по эту сторону реальности уже наступило.
Если же роадмапа нет, можно ориентироваться на спринты или просто взять набор компонентов, который вы разработали с момента начала проекта или после предыдущего демо. Чтобы заранее определить ход демо, мы готовим специальный документ. Сценарий демо, если угодно.
Его лаконичность полностью в нашей власти: можно расписать всё подробнейшим образом и сделать заметки для каждого из участников процесса, или же ограничиться ссылками с названием компонентов/страниц. Тот же документ можно расшарить с клиентом и предложить ему прописать в секциях фидбэк. По моим наблюдениям, это нередко добавляет баллов команде-исполнителю, показывает, что ей и правда интересно мнение клиента о продемонстрированных фичах.
Готовим среду
- стейджинг, на котором вы собираетесь демонстрировать материал, поднят;
- на этот стейджинг могут зайти все участники демо;
- весь материал, который вы собираетесь демонстрировать, задеплоен;
- содержимое этого материала не вызывает у вас удивления.
Совет: будет классно, если весь функционал на стейджинге проверит человек из команды, который не принимал участия в подготовке среды. Просто потому, что он свежим взглядом может заметить гораздо больше 😉
Что касается демонстрации на локальной среде — компьютере одного из разработчиков. На ней, безусловно, можно показывать отдельные фичи. Но помните, что при таком раскладе клиент не сможет самостоятельно покрутить в руках демонстрируемую функциональность. Для него это превратится в ситуацию «продаете — показываем — красивое».
Но тем не менее, если у нас в локали лежит добротная фича, которой по каким-то причинам нет на стейджинге (неполная реализация/работа только при участии духовых инструментов/не успели залить), а откровенно нового в демо мало, — мы её покажем! В конце концов, почему бы приятно не удивить клиента? 😉
Распределяем обязанности и роли
Мне кажется, нет единого «золотого» стандарта, по которому надо определять участников процесса. Есть команды, в которых демо всегда проводит один и тот же человек, и клиент пляшет от восторга. В некоторых случаях выступает вся команда, и тоже получается отличный материал.