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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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