Вы читаете очередной пост из факап-цикла. Я уже рассказывал о том, как маркетинг нанёс смертельный удар продукту и как бухгалтеры едва не превратили пользовательский опыт в катание на адской колеснице. Были посты про монетизацию и гугл-карты, про кластеризацию маркеров там же, про неверный выбор инструментов и про многое другое.
Теперь настало время коснуться одной из самых частых ситуаций, возникающих при создании цифровых продуктов (да и не только их).
Это будет длинный, но яркий пост. Гарантирую.
Виски как способ разобраться в проблеме
Не так давно, около месяца назад, ко мне заявился взмыленный приятель и заявил, что только что уволился с одного отвратительного проекта, на который потратил почти полгода своей жизни. После короткого разговора стало ясно, что проблема была вовсе не в проекте, а в организации работы проектной команды.
Процесс был построен по классике гибких методологий: недельные спринты, ежедневные митинги, приоритизация бэклога, вот это всё. Вроде, обычный и привычный подход, всем давно знакомый. Однако в этот раз что-то пошло не так. То ли бэклог стал распухать до размеров Млечного Пути, то ли изменения стали прилетать чаще, чем команда могла их переварить. Из сбивчивого и эмоционального рассказа приятеля не всё было до конца понятно, мне стало интересно, и я решил углубиться.
Мы отправились в ближайший бар.
Спринты бывают разные
Старый добрый вискарь немного успокоил моего знакомого, и тот поведал весьма трагичную историю. Не новую, впрочем, но оттого не менее актуальную.
Как и у многих, у них в команде были спринты фиксированной длины. Неделя – и хоть убейся. Это стандартная история в agile-подобных подходах: после небольшого проектирования и планирования проектной команде ставится задача, которую они должны решить к определённой, фиксированной дате. Срок выполнения таких задач всегда одинаков и составляет, как правило, неделю или две. В нашем случае этот срок составлял ровно 5 рабочих дней, неделю.
Именно эта фиксация и стала причиной провала и адского выгорания разработчиков с аналитиками и дизайнерами. Чтобы было понятнее, давайте приведу простой пример. Например, с регистрацией.
Время безжалостно
Итак, у нас есть команда разработки приложения. Два мобильных разработчика (iOS и Android), один разработчик серверный, дизайнеры и аналитики. Согласно классическим скрам-традициям, команда решает, что в ближайшем спринте они будут делать основу основ – регистрацию пользователя.
Однако опыт у всех разработчиков разный; технологии, на которых они работают, тоже разные; да и случай также частенько делает своё грязное дело.
В итоге:
- Android-разработчик находит удачный плагин для интеграции SMS-шлюза и полностью заканчивает кодить регистрацию всего за 3 дня.
- Разработчик на iOS такого решения не находит, и тратит на задачу полных 4 дня.
- Серверный программист едва укладывается в срок и закрывает таску вечером в пятницу, обливаясь потом и матеря аджайл.
Конечно, iOS и Android не сидят сложа руки оставшиеся дни, а переключаются на закрытие каких-нибудь багов или реализацию мелких фич. Благо, даже в начале проекта их всегда предостаточно.
Что происходит дальше?
После того, как сервер сдан, приходит QA и начинает тестировать регистрацию. Разумеется, находит мелкие баги. Дёргает мобильных разрабов и просит починить. Те, уже погруженные в другие задачи, вынуждены вырываться из контекста и недовольно исправлять недостатки своего кода.
Такое прерывание контекста является регулярным. Это не особенно благоприятно влияет на динамику работы, скорость создания продукта и его качество.
Плюс, еженедельное вскрытие гештальтов также не способствует укреплению мотивации: каждый раз разработчики с гордостью отправляют задачу на тестирование, и каждый раз оказывается, что задача не закрыта и гордиться тут особо нечем. Причём оказывается не сразу, а спустя несколько дней (в лучшем случае).
Какие выводы делает команда?
Смотрите, серверный разработчик едва-едва успел. Это стало для него реальным стрессом. Чтобы не допускать подобного в следующий раз, он будет писать код немного хуже. Чуть-чуть менее вдумчиво – зато получится быстрее и он точно уложится в спринт.
Android-разработчик решил свою задачу быстрее всех. Да, ему повезло с плагином, но ещё он немного опытнее остальных коллег. Конечно, он делает вывод, что можно вообще не торопиться – всё равно успеет. И начинает иногда работать менее эффективно. Со временем "не напрягаться" становится привычкой.
И только один iOS-девелопер продолжит работать в прежнем ритме.
Понимаете?
Один начинает писать код всё хуже и хуже, и теряет мотивацию из-за тайного недовольства собой. Но не любить себя и не впасть в депрессию сложно. Поэтому он проецирует это недовольство на продукт – и начинает тихо ненавидеть его.
Второй со временем начинает работать всё медленнее и медленнее. И когда появляется действительно сложная задача и дедлайн внезапно оказывается прямо над ухом, ему оказывается невероятно сложно перестроиться и вернуться к прежней динамике. Он не укладывается в спринт и начинает искать оправдания. Которые, разумеется, находит.
Конец истории
Так случилось и с моим приятелем. Команда полностью утратила мотивацию, подобие изначального плана оказалось окончательно погребено под необъятным бэклогом.
Руководители же как будто этого не замечали. Видя падение производительности, они продолжали наращивать темп. Поощряли разработчиков не за качество работы, а за количество закрытых задач в трекере. В итоге даже те, кто работал нормально, стал откровенно халтурить – ведь за это они получали не по шапке, а +20k рублей к зарплате.
Естественно, что вся команда со временем разбежалась. Насколько я знаю, руководство постепенно набрало новую, однако её, скорее всего, ожидает та же судьба. Ну а из-за необходимости обучения и погружения в проект новых людей, процесс разработки рискует стать бесконечным.
История печальная, но, как я уже сказал, встречающаяся повсеместно. Если интересно, я сделаю отдельный пост о том, как решаю её у себя на проектах – пишите в комментариях.
--
Все свои посты я аккумулирую в камерном телеграм-канале, подписывайтесь.