В мире продуктовой разработки мы постоянно ищем способы создания максимальной ценности в кратчайшие сроки. Это позволяет нам быстрее получать обратную связь от клиентов и лучше адаптироваться к их реальным потребностям.
Но как достичь результата быстрее?
Многие думают, что скорость — это самоцель. Однако в реальности важно не столько ускорение процесса, сколько получение качественного результата раньше.
То есть под словом «быстрее» мы всегда подразумеваем «раньше».
В этой статье мы рассмотрим ключевые практики, которые позволяют это делать. А также попутно развеем самые распространённые мифы про ускорение разработки.
🪄 Одно изменение, с которого стоит начать
Мы создаём системы, которые решают проблемы людей и бизнеса.
Обычный процесс разработки выглядит так: компания создаёт продукт, которым пользуются клиенты и за что они платят деньги компании.
Немного утрируя, можно сказать, что чем лучше мы решаем проблемы клиентов, тем больше денег мы зарабатываем.
Однако мы не можем быть на 100% уверены, что новая фича — это именно то, что необходимо нашим пользователям.
Поэтому важно не только раньше дать новую ценность клиентам, но и затратить на это минимум времени команды. И если фича всё же окажется неудачной, то потери будут минимальны. Другое дело, если мы потратим несколько месяцев работы команды…
Грамотная декомпозиция фичи на кусочки позволяет получать результаты на порядок раньше благодаря уменьшению скоупа работ до действительно необходимого.
Столь огромное ускорение не даст ни одна другая практика или изменение процессов.
Подробно про то, как можно декомпозировать фичи, мы рассказывали тут:
Второй по значимости блок изменений, который позволяет ускорить разработку, предполагает управление потоком задач в команде 👇
🚥 Работа с потоком задач
Так или иначе, у вас есть поток из задач и фичей.
Чтобы делать больше и быстрее, вы пробуете управлять и влиять на этот поток. Причём вне зависимости от используемой методологии — будь то Kanban, SCRUM, Scrumban или пр.
При этом в Kanban методе большое внимание уделяется управлению потоком через множество практик, метрик и пр. Это позволяет быстро, ритмично и предсказуемо давать результат. Многое (но не всё) сказанное далее будет пересекаться с мыслями из Kanban.
Если команда работает в итеративных процессах (например, SCRUM, Scrumban и пр.), то у неё так же есть поток задач, хотя и ограниченный сверху временным окном спринта. Соответственно, если есть поток, то его также можно оптимизировать и развивать.
Также многие компании имеют устоявшиеся upstream и downstream процессы на всю компанию, где работа по фичам сведена в один верхнеуровневый проект на всю компанию. И это тоже поток задач, но чуть более высокоуровневый.
🏎️ Практики, ускоряющие разработку
Рассмотрим первые 12 практик из публикации Feels Like Faster vs. Is Actually Faster (Medium), которые также обсуждали на встрече сообщества Современной разработки.
Итак, практики для ускорения разработки:
- 🏁 Прекратите начинать, начните завершать
- ⭕️ Оставляем «воздух» при планировании
- 🐾 Стремимся всё делать последовательно
- 🛣️ Планирование через целеполагание
- 🗂️ Стремимся снизить work in progress (в рамках разумного)
- 👯♀️ Начинаем работу над фичей вместе
- 🥷🏻 Фокус на T-shaped специалистах в команде
- 🔂 Оставляем время на работу с обратной связью от клиентов
- 🛃 Абсолютное качество
- 🐝 Регулярный рефакторинг техники и продукта
- 🤝🏻 Максимальная кооперация разработки и тестирования
- 🛠️ Улучшаем процессы и инструментарий вместо найма людей
Давайте разбираться в каждой из них…
🏁 Практика №1: прекратите начинать, начните завершать
Миф:
Когда мы хотим что-то сделать быстрее, то очень хочется начать делать раньше.
Реальность:
Однако сделать быстрее не про «начать раньше», а про «закончить раньше». Ведь если мы что-то начали делать раньше, то это не значит, что результат также будет раньше.
Чтобы получать результат раньше, команда в первую очередь должна уделять внимание задачам, которые ближе всего к завершению. То есть тем, которые правее на доске. В мире Kanban этот принцип называется «stop starting and start finishing».
На практике это может выглядеть следующим образом: разработчик передаёт свою задачу на code review, но вместо того, чтобы брать в работу новый тикет (из левой колонки), он идёт ревьюить задачи коллег или делать релиз готовых задач (из самых правых колонок).
Тем самым разработчик поможет задачам команды быстрее завершиться и сокращает объём недоделанной работы у команды.
При этом, чем оптимальнее работает поток в команде, тем выше вероятность, что к моменту окончания того самого ревью или релиза, собственная задача этого разработчика уже тоже пройдёт ревью.
И вот мы без сильного разрыва контекста и помогли товарищам по команде, и наша задача стала на шаг ближе к завершению.
⭕️ Практика №2: оставляем «воздух» при планировании
Миф:
Зачастую мы пытаемся утилизировать ресурс команды на 100%, чтобы сделать больше. Ведь если есть свободный ресурс на момент планирования, то почему бы его не занять?
Реальность:
Пропускная способность команды плюс-минус постоянна от недели к неделе. Другими словами, за единицу времени из команды выходит примерно одинаковый объём ценности.
Для значимого изменения пропускной способности нужно либо менять состав команды (временно или постоянно), либо привносить значимые изменения в процессы работы.
При этом на нас действует закон Литтла, одно из следствий которого:
При неизменной пропускной способности мы можем сократить среднее время выполнения благодаря тому, что сократим количество одновременно выполняемой работы
Получается, что при повышении объёма работы после определённого уровня начинается замедление команды.
Это происходит из-за недостатка slack — самое близкое по смыслу в русском языке: зазор, свободное место или «воздух».
Если команде недостаточно «воздуха», то сотрудники ощущают давление по срокам и скорее сосредоточены на попадании в дедлайны по своим задачам, а не на общих целях команды и ценности для клиентов.
Однако когда у команды достаточно «воздуха», её члены могут уделить время на помощь друг другу в завершении задач — например, на code review или тестирование. То есть у людей есть время на то, о чём мы говорили в практике №1.
Но здесь важен баланс — не слишком много и не слишком мало. Обе ситуации одинаково негативно влияют на скорость команды.
🐾 Практика №3: стремимся всё делать последовательно
Миф:
Интуитивно кажется, что если есть возможность, то сто́ит взять ещё одну задачку в параллель. Тем самым быстрее получить результат.
Реальность:
Когда мы берём себе ещё одну задачку в параллель, мы растим объём незавершённой работы.
Пока задачи не закрыты, мы вынуждены регулярно переключать контекст между ними, что требует порядка 3–5 минут на само переключение и ещё до 20 минут, чтобы снова войти в состояние потока.
Также, когда у человека много незавершённых дел, он чувствует давление и тревогу, что приводит к спешке и развитию стресса.
С другой стороны, делая всё максимально последовательно, мы можем сфокусировано доводить до завершения свою работу, избежать лишнего стресса и чувства постоянной спешки.
Подробно про это мы говорили в статье про Многозадачность и сфокусированную работу:
Но не сто́ит бросаться в крайности наподобие 1 активной задачи на каждого члена команды в единицу времени (или, другими словами, WIP лимита = 1).
🛣️ Практика №4: планирование через целеполагание
Миф:
Каждый свободный таймбокс заполняем максимально близкой по оценке задачей к размеру таймбокса.
Чтобы точно наполнять таймбоксы, команда стремится давать всё более и более точные оценки, инвестируя значимые силы в проработку, «улучшение» оценок и планирование.
Этот миф во многом развивает историю о 100% утилизации ресурсов, про которую мы говорили выше.
Реальность:
За время работы руководителем в разработке у меня сформировалась следующая позиция про планирование и реализуемость наших планов:
- Мы не знаем всего того, чего не знаем — даже если уверены, что знаем всё
- Мы не настолько точны в предсказаниях, как сами думаем
- То, о чём мы не знаем, обязательно станет для нас сюрпризом в самый неподходящий момент и значимо повлияет на наши планы
- Мы обязательно однажды окажемся неправы в вопросах, где даже представить себе не можем — это лишь вопрос времени
Другими словами, на момент начала работы мы никогда не будем знать всего, что нам предстоит. Соответственно, у нас не может быть точной оценки на старте.
Поэтому сто́ит больше вкладываться в то, чтобы делать дела, идти вперёд и уже в моменте решать то, о чём мы не знаем, и что обязательно встретится нам на пути.
Но важен баланс… Оголтело с шашкой на перевес бежать фигачить без понимания того, что мы делаем и зачем тоже не стоит.
Вопрос в том, сколько усилий и времени рационально уделять проработке фичей.
У каждой команды есть своя точка перегиба: до неё сумма вложенных усилий в проработку и оценку способствует повышению скорости команды, а после — уже замедляет.
Когда мы работаем в плоскости неопределённости, единственный эффективный способ планирования — это целеполагание. То есть при планировании таймбокса мы формируем для него цель, а не «заполняем задачами под завязку».
🗂️ Практика №5: стремимся снизить work in progress (в рамках разумного)
Миф:
У нас в команде есть 5 инженеров. Мы можем в каждого положить разные фичи и задачи. Итого сделаем в 5 раз больше!
Реальность:
Действуя так, мы увеличиваем у команды количество разных фичей в работе (Work in progress, WIP).
Это приводит к ряду негативных последствий:
- Снижение общей производительности команды — члены команды чаще переключают контекст между задачами, что увеличивает время выполнения каждой отдельной задачи. Так работает закон Карлсона в масштабе.
- Снижение качества и увеличение ошибок — при переключении контекста, могут теряться из вида важные детали. Особенно если фичи сильно про разное.
- Замедление онбординга новичков — они вынуждены часто прыгать между разными фичами и задачами, что усложняет их погружение в зону ответственности команды. Слишком сложно сложить общую картинку.
- Снижение вовлечённости — частые переключения между фичами размывают ощущение результата от своей работы и, как следствия, понимания её ценности.
Поэтому необходимо снижать число WIP фичей в команде и фокусировать команду на чём-то определённом.
Вкупе с практиками про фокус на завершение задач и наличие «воздуха» в работе мы получаем ещё большее ускорение. Поскольку вся команда сфокусирована на минимальном числе целей, по которым работают все члены команды (а не каждый над своей).
Однако слишком низкий уровень WIP тоже нежелателен, т.к. может привести к простою команды в то время, когда могла бы принести пользу клиентам.
Оптимальный уровень WIP зависит от специфики проекта, размера команды и множества других факторов. Подбирается экспериментальным путём.
👯♀️ Практика №6: начинаем работу над фичей все вместе
Миф:
Порой кажется, что если вот мы сейчас можем начать работу над фичей, когда другие участники ещё не готовы, то однозначно надо начинать.
Что сидеть-то без дела! Дальше ребята подхватят, а у нас всё готово будет. Только о контракте договоримся.
— фраза, которую я слышу слишком часто
Встречается как в случае работы внутри одной команды, так и когда финальный результат зависит сразу от нескольких команд.
Реальность:
Наша основная задача — получить результат раньше.
Начиная работу по своей части раньше остальных участников фичи, мы лишь «сделаем» свой кусочек раньше, а общий результат по-прежнему где-то там далеко.
Но действуя так, мы получаем и ряд неприятных последствий для команды:
- Увеличивается объём работы по фиче — непредвиденные изменения в одной из частей в будущем могут потребовать значительных усилий для того, чтобы собрать всё вместе. А вы ведь уже всё сделали, да?
- Теряется общее ви́дение фичи — работая независимо, все участники могут иметь разное ви́дение фичи, что может привести несогласованности в конечном продукте.
- Повышается объём недоделанной работы в команде — ведь ещё какое-то время фичу никто не подхватит дальше по процессу — тем самым увеличивается WIP у команды и замедляем её (и снова этот закон Литтла, о котором говорили выше).
- И ещё больше увеличивается объём работы — чем дольше ваша часть лежит без дела, тем выше вероятность, что её придётся переделывать. Продукт и сервисы развиваются каждый день. Любая другая фича может помешать вам запуститься.
Но что самое важное, вы теряете возможность поставить ценность клиентам в моменте. Ведь команда потратила время, а клиент пока ничего не получил 🤷♂️
С другой стороны, за это время вы могли бы поработать по другим фичам, где ценность можно получить здесь и сейчас. Пусть даже ценности будет меньше, но зато клиенты и компания смогут извлекать пользу из новой фичи!
В этом помогает практика, когда мы стремимся начинать работу вместе — по всем частям фичи разом. Насколько это возможно.
Дополнительно мы получаем тесную кооперацию между участниками в моменте, что позволяет меньше деталей проработать вначале и ускоряет решение всех сложностей в процессе.
🥷🏻 Практика №7: фокус на T-shaped специалистах в команде
Каждый руководитель стремится собирать команду лучших из лучших на рынке. Но кто есть «лучший»?
Миф:
Нанимаем в команду людей с крайне сильно развитыми hard-скилами, которые могут быстро и много писать кода, проворачивать архитектурно сложные задачи и пр.
Реальность:
Существует два пограничных вида сотрудников:
- Узкие специалисты (I-shaped) — идеально разбираются в своём деле, но у них ровно одна сильная сторона. При этом то, что происходит вокруг, их не особо интересует.
- Генералисты (M-shaped) — хорошо разбираются во многом, что нужно в работе. Но при этом в большинстве сфер они будут слабее, чем отдельно взятые узкие специалисты по каждой из сфер.
Между ними есть наиболее распространённые T-shaped специалисты, которые как хороши в чём-то одном, так и разбираются в смежных областях.
Ключевая особенность кросс-функциональной продуктовой команды — это высокий уровень самоорганизации и автономности команды, что возможно только при тесной кооперации всех членов команды. Для этого необходимо понимать и вовлекаться в детали работы «соседа» — будь они разработчиками, тестировщиками, дизайнерами, продактами и пр.
Поэтому в большинстве случаев T-shaped сотрудники будут нести большую пользу вашей команде и компании. И чем в большем числе сфер они будут постепенно разбираться, тем ближе они будут к генералистам.
При этом «верхняя планка» не должна быть длиннее «ножки» в их «T-shape». Иначе вы окажетесь в ситуации, когда человек знает про всё, но не разбирается ни в чём.
Бывают моменты, где найм узкого специалиста в команду будет в полной мере оправдан, но это скорее исключение из правил.
В моей практике такое было всего 2 раза из более чем 100 нанятых мной людей, подробнее про эти кейсы…
🧬 В команду, которая создавала систему рекомендаций на основе генетических тестов, мы искали разработчика с прикладными знаниями в биоинформатике, чтобы лучше простроить мостик между командой разработки и учёными-генетиками. Слишком большой разрыв был в нашем понимании друг друга
📦 Для сервиса доставки товаров в команду, которая осуществляет выбор оптимального курьера для вашего заказа, был необходим человек с крайне высокими алгоритмическими навыками. На тот момент команда за 20% усилий уже получила 80% результата в части эффективного распределения заказов. Дальнейшие шаги были слишком дорогими и требовали уже особенных знаний.
🔂 Практика №8: оставляем время на работу с обратной связью от клиентов
Миф:
Когда мы завершили фичу, то можно сразу начинать делать следующую.
И так раз за разом от недели к неделе, спринта к спринту, и т.д.
Реальность:
Действуя подобным образом, мы действительно можем получить следующую фичу раньше.
Однако это негативно сказывается на продукте, ведь мы не даём себе возможности разобраться:
- А то ли мы сделали по последней фиче, что было нужно?
- Счастливы ли наши клиенты?
- Начали ли они использовать эту новую фичу?
- Или мы выкатили что-то, чем пользуется полпроцента клиентов, и счастливее особо никого не сделали, но потратили пару недель работы команды?
Регулярно добавляя новые фичи, но не развивая их и не адаптируя под обратную связь от клиентов, мы усложняем наш продукт.
Появляется несогласованность, ухудшается пользовательский опыт и общая удовлетворённость от продукта.
В какой-то момент, когда появится достаточно качественный альтернативный продукт, ваши клиенты перейдут на него. Ведь какой смысл им продолжать «есть кактус»?
Чтобы избежать подобного, необходимо оставлять себе время собрать обратную связь с пользователей и обдумать, насколько успешно всё получилось, как улучшить фичу и пр.
Именно такой подход делает нас agile в том самом каноничном виде — где можем быстро меняться по обратной связи от наших пользователей.
🛃 Практика №9: абсолютное качество
Когда мы сталкиваемся с несовершенством того, что создали, — будь то баги, не самый удобный интерфейс и пр. — мы встаём перед дилеммой: исправить до релиза или как-нибудь потом.
Миф:
Чтобы получить результат быстрее, можно отложить исправления на будущее. Главное — попасть в срок.
Реальность:
Срезая таким образом углы, ваши клиенты получают несовершенную и неполноценную фичу.
Да, вы успели в срок и создали то, что требовалось. Но посредственно выполненная работа в срок по-прежнему остаётся посредственной.
Также попустительство к маленьким недочётам постепенно приведёт к тому, что для команды станут приемлемы сначала средние, а потом и огромные косяки — так проявляется теория разбитых окон.
Если в процессе работы вы осознаёте, что клиенту будет неудобно пользоваться вашей фичей, то самое время действовать — заполировать и улучшить UX.
Здесь важен баланс. Уход в перфекционизм будет столь же деструктивен для продукта, как и срезанные углы.
Найти оптимум помогает «мышление новичка» — когда мы отбрасываем всё, что знаем про наш продукт, и из этого состояния спрашиваем себя:
- Понятно ли мне, какую ценность даёт эта фича?
- Могу ли я с лёгкостью воспользоваться фичей и получить максимум?
- Как фича вписывается в продукт в целом и мои проблемы, которые я решаю этим продуктом?
- Что мешает мне с комфортом решить свою проблему?
Благодаря такому рефреймингу мы находим пути улучшить пользовательский опыт для наших клиентов.
🐝 Практика №10: регулярный рефакторинг техники и продукта
Каждая фича уникальна — как минимум из-за контекста вашей команды и компании.
Поэтому зачастую не получается выбрать грамотное техническое, архитектурное решение. Да и в части продукта порой не получается с первого раза сложить верную картинку.
Одновременно с этим мы стремимся запускать новые фичи быстрее. Ради чего порой стартуем с меньшими возможностями или удобством для пользователя.
Всё это порождает долги — технический, продуктовый, UX-овый и т.д.
Миф:
Через месяц запланируем «технический спринт», где будем всё рефакторить и закрывать техдолг.
Реальность:
Интуитивно хочется пойти по такому пути. Договориться с бизнесом и целый спринт заниматься только рефакторингом! А то и два подряд, ух…
Но обычно довольно сложно как договориться, так и потом уложить все наши планы в то самое выделенное время.
А пока мы ждём — счётчик неправильных решений и срезанных углов продолжает тикать. Долги копятся.
При этом мы зачастую забываем про долг в части продукта и пользовательского опыта, который также постепенно растёт.
Чтобы долг не стал неподъёмным, его нужно регулярно выплачивать — занимаясь рефакторингом наравне с созданием новых фич.
Каждый спринт, каждую неделю часть времени команды следует направлять на закрытие как техдолга, так и развитие пользовательского опыта в текущих фичах.
Также, чтобы закрыть те или иные несовершенства системы, нам может быть полезно просто поэкспериментировать без конкретного плана на рефакторинг проблемного участка. Всё-таки разработка — это во многом творческий вид деятельности.
Вписать такой подход в работу команды помогает фреймворк баланса фокусов команд, про который мы рассказывали в этой статье:
🤝🏻 Практика №11: максимальная кооперация разработки и тестирования
Миф:
Каждый должен делать свою часть работы. Разработчик пишет код, тестировщик — тестирует.
Реальность:
Зачастую вижу в командах разработки подобную картину:
- Разработчик подвинул тикет в статус «Готово к тестированию» и, условно, забыл про него. После чего взял себе новый тикет и пошёл писать код.
- Тестировщик взял тикет, наклепал багов в Jira и вернул тикет на доработку. После чего взял следующий.
Сделал ли каждый свою работу? — Безусловно, да.
Но что мы получили? — тикет кидают туда-сюда, и каждый раз он ждёт, когда нужный человек освободится от очередной задачи, которую до этого взял в работу.
И при всём при этом у команды растёт объём невыполненной работы (WIP), что замедляет нас, как вы наверняка помните из практик № 1 и 5.
Альтернатива такому формату взаимодействия: тесная кооперация в формате парной работы.
Например, это может выглядеть так: разработчик передаёт свою задачу тестировщику, они садятся вместе (на звонок или рядом в офисе) и проходятся вместе по всей функциональности. Все найденные баги исправляются в моменте, после чего работа над задачей завершается и число WIP уменьшается.
При этом не обязательно делать вместе прям всю работу, но значимую её часть — вполне полезно.
Возможность применять подобную практику напрямую зависит от объёма ваших фичей. Чем лучше вы декомпозируете их на кусочки, тем проще будет команде.
🛠️ Практика №12: улучшаем процессы и инструментарий вместо найма людей
Миф:
У нас есть команда из 6 чел. и мы хотим делать больше фичей. Давайте наймём х2 людей, чтобы получать в 2 раза больше результата.
Реальность:
Увы, но команды и продукт таким образом не масштабируются.
При добавлении новых людей в команду увеличивается число каналов коммуникации между ними. Чем больше каналов, тем сложнее координация работы. А усложнение координации приводит к постепенному замедлению команды.
Именно этим обусловлено правило «двух пицц» в Amazon при формировании команды.
Если рядом добавить ещё одну команду, но при этом не выделить грамотно их зону ответственности, то мы получим тот же самый эффект. Это произойдёт из-за того, что люди в 2-х командах будут конкурировать за один ресурс — одни и те же фичи, один и тот же код, и пр. При этом команды моментально потеряют ви́дение целостной картинки продукта, т.к. правки одной команды не будут известны другой.
Основной фактор повышения эффективности работы команды — это сокращение временны́х издержек. В первую очередь времени простоя и ожидания, когда инженер или задача просто чего-то ждут.
Например, время релиза фичи на тестовый стенд, или время нахождения задачи в статусе Ready for Code Review, или время работы автотестов в CI, или др.
Сокращая такие издержки, мы напрямую влияем на уменьшение Cycle Time. Благодаря этому задачи завершаются быстрее, и мы можем увидеть результат раньше.
🤔 Итого, что всё же нас замедляет, а что ускоряет
Производительность работника умственного труда не измеряется количеством или объёмом – во всяком случае это далеко не самый главный показатель. Зато качеству придаётся огромное значение.
Для повышения производительности работника умственного труда необходимо смотреть на него не как на «издержки», а как на «капитал», и обращаться с ним соответственно.
— Питер Друкер, один из самых влиятельных теоретиков менеджмента XX века
Мы разобрали 12 практик, которые действительно позволяют ускорять разработку.
Все они не самые очевидные, а зачастую и вовсе контринтуитивны. Особенно для людей не из мира IT. Мифы из статьи — это то, с чем я регулярно сталкиваюсь в своей работе.
В моей практике было крайне мало команд, кто задумывался про применение в своей работе практик, описанных в этой статье. А многие из тех, кто применяет их, просто берут название, но не реальное содержимое.
Создание продукта — это умственный труд, где сотрудники, как водители со своей машиной, — каждый приходит со своим собственным станком.
И даже больше — в продуктовой разработке основной результат даёт команда, а не отдельные люди.
Именно поэтому важно создавать условия для эффективного взаимодействия и роста всей команды, а не пытаться увеличивать «скорость» и численность команды, клепать больше тасок, срезать углы и пр.
🏄♂️ С чего начать
Эти практики во многом про привычки и культуру команды. Чтобы их изменить требуется значительное время и усилия.
Будьте готовы, что изменения произойдут не слишком быстро, даже если вы будете уделять им достаточно внимания.
Итак, как вы можете действовать:
- Выберите первую практику
- Примерьте её на работу вашей команды и оцените, насколько вы ей следуете — просто последите несколько дней или неделю за работой команды через призму выбранной практики
- Предложите команде попробовать эту практику в работе в течение, например, 1–2 спринтов/недель
- Пристально смотрите, что происходит, и корректируйте работу людей в команде через обратную связь — порой привычный ход вещей будет выталкивать новшества
- Подведите итог вместе с командой
- Возьмите следующую практику и повторите шаги 1 – 6.
Можете попробовать взять в работу сразу 2–3 практики. Главное, чтобы на шаге 4 вам хватило фокуса на все практики.
Не пробуйте применить сразу все практики. Это потребует слишком больших усилий от всей команды, что не позволит закрепить ни одну из практик в быту команды.
И если будете готовы, то поделитесь результатами в комментариях к этой статье для будущих читателей 😉
Тебя заинтересовали идеи из статьи и ты хочешь попробовать их в своей работе?
Я с радостью помогу применить всё в работе. Бесплатно. Просто напиши мне 👇
💎 Послесловие
Ускорение разработки — это не про «делать быстрее», а про «получать большие результаты раньше».
Для этого необходимо создавать условия, в которых команда может эффективно и качественно выполнять свою работу, быстро адаптироваться к обратной связи от пользователей и постоянно улучшать свой продукт.
Следуя приведённым практикам и идеям в этой статье, вы сможете не только ускорить процесс разработки, но и повысить комфорт работы всей команды.
Удачи 🚀
Добавить комментарий
Для отправки комментария вам необходимо авторизоваться.