Как мы увеличили скорость работы команды на 64% без потери нервов и денег

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

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

О поиске проблем в работе команды и возможных методах их решения — в нашей статье.

Проблемы или "Узкие места" и с чем их едят

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

Самая понятная аналогия, которая нам сразу пришла в голову, — эффект песочных часов из Теории ограничений. Представим его наглядно:

Песочные часы — наглядный пример "узкого места"

Мы опробовали несколько методов поиска "узких мест"(о них мы расскажем в следующей статье) и выявили в нашей работе три основных проблемы:

  1. Завышенные требования к MVP
  2. Завышение оценки времени на выполнение задачи
  3. Перекладывание ответственности или ее отсутствие

Перейдем к решению этих проблем:

1. Завышенные требования к минимально жизнеспособному продукту (MVP)

Минимально жизнеспособный продукт (minimum viable product, MVP) — продукт, обладающий минимальными, но достаточными для удовлетворения первых потребителей функциями. Основная задача — получение обратной связи для формирования гипотез дальнейшего развития продукта. - (с) Википедия

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

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

Проблема

- В чем же здесь проблема? — спросите вы.

Проблема заключается в том, что MVP в процессе разработки изменялся до неузнаваемости, а из-за потраченного времени на исправление ошибок и выполнение разных доработок вся проделанная работа улетала в трубу.

Решение

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

По нашей оценке, это увеличило скорость выполнения проектов на 14%

2. Завышение оценки времени на выполнение задачи

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

Проблема

Наверное, большинству известно о законе Парето, но мы на всякий случай напомним.

20 % усилий дают 80 % результата, а остальные 80 % усилий — лишь 20 % результата.

Вильфредо Парето, итальянский инженер, экономист

Как оказалось, этот закон действительно работает, по крайней мере, в нашем случае он работал на все 100. Оказалось, что наши дизайнеры и программисты закладывали на 30% больше времени для "доделок и правок" в каждую задачу.

Решение

Данная проблема решается предельно просто. Достаточно было всем разъяснить новые принципы работы: сначала выполнить как можно быстрее любую задачу, не вкладывая в нее "лишнее" время, а правки представлять отдельной задачей.

По нашей оценке, это увеличило скорость выполнения проектов на 28%

3. Перекладывание ответственности или ее отсутствие

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

Проблема

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

Решение

По принципам Scrum мы работали уже больше года к моменту этих нововведений, но они не давали нужного результата. Мы собирались на еженедельные "митинги" и нам казалось, что этого вполне достаточно.

Для полноценного курирования проектов мы ввели так называемых Scrum-лидеров в лице менеджеров проектов и переложили полную ответственность за проект на них. Кроме этого, "митинги" стали ежедневными, благодаря чему все проблемы теперь решаются гораздо быстрее.

По нашей оценке, это увеличило скорость выполнения проектов на 22%

Выводы

Такими нехитрыми и достаточно простыми методами мы добились ускорения выполнения задач на 64%. Эксперимент занял около 2-х месяцев, а внедрение новых методов — не более недели.

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

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

0
14 комментариев
Написать комментарий...
Sergei Timofeyev

Скажите, насколько чаще начала обновляться команда? Уровень стресса, к сожалению, одной мотивацией не снижается, равно как и резистивность к нему не растёт.

Поле для оптимизации у вас ещё очень большое. :)

Ответить
Развернуть ветку
Антон Соболев
Автор

Согласен в Вами, уровень стресса заслуживает, по крайней мере, отдельной статьи. С тех пор никто их команды нас не покинул, даже увеличили штат. :)

Ответить
Развернуть ветку
Sergei Timofeyev

Ну так всего 2 месяца.

Ответить
Развернуть ветку
Антон Соболев
Автор

Да, стоит отметить, что все изменения никак не сказались на мотивации сотрудников.

Ответить
Развернуть ветку
Shoo

Что в данном случае понимается под скоростью выполнения проектов?
Как все эти изменения сказались на остальных метриках проекта, помимо скорости?
Насколько вырос процент задач по внесению изменений в уже реализованную функциональность?
А с качеством что?

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

Ответить
Развернуть ветку
Антон Соболев
Автор

Под скоростью понимается, что проекты начали выполняться быстрее.
Остальные метрики остались примерно на том же уровне, качество итогового продукта не ухудшилось.
Процент правок вырос примерно на 30%, но это не играет никакой роли, т.к. проекты начали выполняться быстрее, даже с этими правками.

Ответить
Развернуть ветку
Shoo

Окей, перефразирую, что вы подразумеваете под "Проект выполнился"?
Как меряете скорость?
Про "это не играет никакой роли" спасибо, поржал. А мужики-то не знают, все ещё верят во всякие экспоненциальные графики про кост внесения изменений в продукт относительно времени и кококо.

Ответить
Развернуть ветку
Антон Соболев
Автор

Проект выполнится, когда его отдают заказчику в готовом виде. Это вполне очевидно. Вот как раз время от начала работы над проектом до принятия у заказчика уменьшилось на те самые 64%.

Ответить
Развернуть ветку
Shoo

Именно по этой причине и спрашивал. Вы сократили время работы над проектом, а не увеличили скорость работы. Это разные вещи.
Сокращение времени работы над проектом ничего не говорит об эффективности работы, т.к. скорость это отношение объема работы к времени.
А в кейсе с "уменьшилось время до принятия заказчиком" объем работы не учитывается.

Ответить
Развернуть ветку
Антон Соболев
Автор

1. "Сокращение времени работы над проектом ничего не говорит об эффективности работы" - как раз таки говорит: если на проект был заложен месяц, а его сделали да 3 недели, разве это не увеличение скорости работы? Как раз оно в чистом виде.

2. "объем работы не учитывается" - объем работы не имеет смысла учитывать, если внедрить понятие скорости выполнения задач. Только на него надо ориентироваться.

Ответить
Развернуть ветку
Shoo

Скорость это делаем N работы за X времени
Сделали X/2 работы за N/2 времени - это не увеличение скорости.
То, что вы описываете - банальное перекидывание костов с этапа разработки на этап поддержки.

Ответить
Развернуть ветку
Антон Соболев
Автор

Скорей всего вы просто не так поняли саму суть: мы перестали делать именно лишнее доработки. Быстрее получаем фидбек от заказчика и уже по нему ориентируемся.

Ответить
Развернуть ветку
Антон Соболев
Автор

Ждем еще комментариев)

Ответить
Развернуть ветку
Oleg Krasikov

Вы же понимаете, что "это" нельзя называть скрамом?

"Как оказалось, этот закон действительно работает, по крайней мере, в нашем случае он работал на все 100. Оказалось, что наши дизайнеры и программисты закладывали на 30% больше времени для "доделок и правок" в каждую задачу."

И то, что на скриншоте, тоже

Ответить
Развернуть ветку
11 комментариев
Раскрывать всегда