Без ТЗ: Как запустить сервис и ничего не упустить. Аутсорсинг разработки цифровых продуктов | страница 20
Вертикальная декомпозиция. Источник – https://creativecommons.org
Я предпочитаю не углубляться в подробности реализации задач, если только разработчики сами этого не попросят.
Усмирение демонов
Допустим, план на спринт готов, критерии приемки чётко сформулированы и команда приступила к разработке. Обсудим несколько базовых правил, чтобы всё шло так, как должно.
Всегда давайте возможность разработчикам предложить вам несколько вариантов решения задачи. Ни в коем случае нельзя настаивать только на вашем конкретном варианте. Помните: пока продукт не запущен и нет возможности посмотреть на статистику его использования, все гипотезы равнозначны.
Если вы не можете избавиться от мысли, что ваше решение задачи самое лучшее и других вариантов быть не может, грамотный исполнитель предложит провести A/B-тест. Зафиксируйте ваше решение в отдельной таблице работы с гипотезами и двигайтесь дальше.
Старайтесь, чтобы у каждой задачи, которая идёт в спринт, был понятный результат, а не «провести исследование как провести исследование». Вообще, в гибкой разработке не принято выделять исследования в отдельные задачи, потому оценивать качество таких активностей и управлять ими затруднительно.
В гибкой методологии срок исполнения равен сроку завершения спринта. Если от спринта к спринту часть задач не выполняется – ничего страшного, это абсолютно нормальное явление. Зато после прохождения нескольких спринтов вы будете лучше понимать средний объём задач, который команда успевает «переварить», и в следующий раз не будете переживать о нескольких задачах, которые не успели решить. Просто держите приоритетность под контролем – и среди невыполненных задач окажутся не такие уж и важные.
Аппетит приходит во время еды
Возможно, у вас появится соблазн сказать: «Давайте пока закроем задачу, а потом немного доделаем!» Покорный исполнитель смирится и отправит задачу в колонку «готово». Но это неправильно. Так вы перестанете управлять сроками и качеством исполнения. Запомните: у задач не может быть статуса «почти сделана». Либо она готова полностью, либо не готова.
Если вы захотите внести какое-либо улучшение – закройте текущую задачу, сформулируйте новую, типа «улучшение такой-то функциональности», и отправьте её в конец бэклога, чтобы во время планирования следующего спринта обсудить её приоритетность и возможные варианты решений вместе с командой. Вот тогда вы и разберётесь, насколько она важна. А пока наберитесь терпения. Такие ситуации неизбежны.
