День 98. Оценивание в аутсорсных командах (II)

Почему оценки проваливаются?

Факторы, влияющие на оценки

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

Начнем с того, что вопреки расхожему мнению о том, что в срыве сроков виноваты только разработчики (ведь именно они разбираются и могут дать точную оценку), есть множество других факторов:

1. непредсказуемость

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

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

Это приводит к сложности оценок и, как следствие, к продалбыванию (как говорит Макс Дорофеев) сроков.

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

После этого мы выработали подход, который позволил нам избегать подобных ситуаций в будущем.

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

Это позволяет нам оценить скорость команды и в дальнейшем называть более конкретные сроки реализации.

2. Требования

Product owner (или внешний заказчик) должен быть на одной воле с командой разработки, чтобы обеспечить эффективную работу. Это настолько важно, что во многих компаниях каждый клиент закреплен за каким-либо менеджером, отвечающим за его коммуникацию с командой. Менеджеры берут на себя предоставление отчетов, проведение митингов и другие организационные вопросы. Разработчики, таким образом, концентрируются на том, что у них получается лучше всего.

Подготовка полных и корректных требований — тоже задача менеджера.

Какие проблемы несет неполная документация?

— она создает домыслы и неверные толкования

— она увеличивает длительность предварительного этапа, поскольку разработчикам приходится уточнять детали

— имея ограниченную информацию, команда сможет дать лишь грубую, далекую от реальности оценку

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

Поэтому какой-то функционал, на который были потрачены ресурсы, может перестать быть актуальным.

Пример. В моей практике достаточно часто были проекты, на которых появлялись схожие ситуации. Либо мы получали неточные спецификации, либо заказчик имел достаточные представления о продукте, но не был уверен в деталях. Единственное, что можно сделать в таких условиях — общаться с заказчиком, задавать неудобные вопросы и добывать необходимую информацию.

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

Как итог, каждый участник проекта будет иметь совпадающую картинку.

3. Фиксирование дедлайнов и требований

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

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

Пример. Один член команды за спринт выполняет три задачи. Если в процессе спринта придут две новые задачи, то

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

— эти задачи будут перенесены на следующий спринт

— для реализации будут привлечен дополнительный разработчик

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

Обсудить у себя 0
Комментарии (0)
Чтобы комментировать надо зарегистрироваться или если вы уже регистрировались войти в свой аккаунт.

Войти через социальные сети:

Сахаров Денис
Сахаров Денис
сейчас на сайте
Читателей: 21 Опыт: 786.781 Карма: 6.74063
все 22 Мои друзья