Карьера Антон Соболев
398

Как мы увеличили скорость работы команды на 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-х месяцев, а внедрение новых методов — не более недели.

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

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

Материал опубликован пользователем. Нажмите кнопку «Написать», чтобы поделиться мнением или рассказать о своём проекте.

Написать
{ "author_name": "Антон Соболев", "author_type": "self", "tags": [], "comments": 14, "likes": 0, "favorites": 18, "is_advertisement": false, "subsite_label": "hr", "id": 47336, "is_wide": false, "is_ugc": true, "date": "Mon, 29 Oct 2018 09:56:58 +0300" }
{ "id": 47336, "author_id": 209758, "diff_limit": 1000, "urls": {"diff":"\/comments\/47336\/get","add":"\/comments\/47336\/add","edit":"\/comments\/edit","remove":"\/admin\/comments\/remove","pin":"\/admin\/comments\/pin","get4edit":"\/comments\/get4edit","complain":"\/comments\/complain","load_more":"\/comments\/loading\/47336"}, "attach_limit": 2, "max_comment_text_length": 5000, "subsite_id": 199121 }

14 комментариев 14 комм.

Популярные

По порядку

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

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

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

Ответить
0

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

Ответить
0

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

Ответить
0

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

Ответить
0

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

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

Ответить
0

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

Ответить
0

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

Ответить
0

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

Ответить
0

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

Ответить
0

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

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

Ответить
0

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

Ответить
0

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

Ответить
0

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

Ответить
0

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

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

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

Ответить
0
{ "page_type": "article" }

Прямой эфир

[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox_method": "createAdaptive", "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fizc" } } }, { "id": 4, "label": "240х200_mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "flbq" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjog" } } }, { "id": 10, "disable": true, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "disable": true, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "bscsh", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "createAdaptive", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-223676-0", "render_to": "inpage_VI-223676-0-1104503429", "adfox_url": "//ads.adfox.ru/228129/getCode?pp=h&ps=bugf&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid10=&puid21=&puid22=&puid31=&puid32=&puid33=&fmt=1&dl={REFERER}&pr=" } }, { "id": 15, "label": "Плашка на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byudx", "p2": "ftjf" } } }, { "id": 16, "label": "Кнопка в шапке мобайл", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byzqf", "p2": "ftwx" } } }, { "id": 17, "label": "Stratum Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvb" } } }, { "id": 18, "label": "Stratum Mobile", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvc" } } }, { "id": 19, "label": "Тизер на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "p1": "cbltd", "p2": "gazs" } } } ]
Голосовой помощник выкупил
компанию-создателя
Подписаться на push-уведомления
{ "page_type": "default" }