E-5

Блог E5

Заметки с передовой ИТ мира Украины ;)

  • Главная
    Главная Страница отображения всех блогов сайта
  • Категории
    Категории Страница отображения списка категорий блогов сайта.
  • Теги
    Теги Список тегов, используемых в блогах.
  • Блоггеры
    Блоггеры Список лучших блоггеров сайта.
  • Блоги групп
    Блоги групп Список лучших командных блогов.
  • Авторизация
    Авторизация Форма для авторизации

Типичные ошибки при коммуникации с клиентами: часть 2

Добавлено : Дата: в разделе Articles
  • Размер шрифта: Больше Меньше
  • Просмотры: 3645
  • 0 комментариев
  • Оформить подписку
  • Печать

Мы продолжаем цикл статей об типичных ошибках в общении с заказчиками. Если прошлый раз мы говорили о «граблях» при интеграции с 3rd party системами, то сегодня поговорим об одинаковых словах с разным значением для разных людей. 

Common sense не существует... Или управление ожиданиями заказчика

Уверенны, у каждого из вас есть в прошлом не одна смешная и не очень история о том, что вроде-бы договорились, запустили в разработку, а на демо от заказчика слышишь:

- А такая-то функция где? 

- Как где, мы же и не должны были ее делать.

- Как не должны! В этой задаче и подразумевалось, что вы сделаете еще и 3-х уровневую проверку на валидность данных! 

b2ap3_thumbnail_-3.png

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

Думаю, уже многие потянулись в карман за рецептом в виде «Да пропишите же Definition of Done!». Действительно, толковый совет, особенно, если добавить Definition of Ready. Давайте же разберем эти 2 термина.

Definition of Done или же определение, что задача выполнена – это набор критериев, по которым мы определяем, что конкретная задача готова. В зависимости от компании, проекта и команды он может быть разным. 

К примеру, в некоторых проектах обязательным будет протестировать не только на QA, но и на UAT или же даже залить на Production. Где-то unit tests будут обязательными, как и code review другим разработчиком, а где-то – нет. Где-то нужно только вручную протестировать, а где-то и полностью покрыть авто тестами. 

Очень желательно обсудить ваш личный Definition of Done с командой, Product Owner/заказчиком, зафиксировать и переодически сверяться с ним в процессе разработки. 

Definition of Ready или же определение готовности – это набор критериев, которые обычно применяются к бизнес требованиям, к примеру, User Story. 

Очень рекомендую его обсудить и создать с командой и Product Owner/заказчиком. Особенно в случае, если у вас прослеживается тенденция брать сырые требования в спринт, в процессе выяснять все детали, и в результате не успевать все сделать в запланированные сроки. Сюда можно включать, к примеру, наличие соответствующих mock-ups/дизайна. Или же утвержденная схема реализации от архитекторов проекта. В некоторых проектах мы даже заводили отдельный статус для задачи – Groomed, который означал, что задача готова к тому, чтобы быть взятой в разработку и у разработчиков нет по ней открытых вопросов. 

В следующих наших статьях мы продолжаем рассматривать ошибки в коммуникации. Следите за нашими новостями!

 

0
Trackback URL для этой записи блога

Комментарии

  • Пока еще не оставлено не одного комментария. Будьте первым!

Оставить комментарий

Гость Четверг, 23 Ноябрь 2017
закрыть
Здравствуй, милый человек!

Надеюсь тебе понравится на нашем сайте! У нас много интересной информации и очень отзывчивое комьюнити. Добро пожаловать :)

Контакты

E-mail: info @ e-5.com.ua
Адрес: Киев, ул. Московская, 27
Тел.: +380677906611

Ищите нас в

Подписаться на новости