Что нужно, чтобы быть высокопроизводительной командой разработчиков, не идущей на компромисс

Трудно найти баланс между качеством и сроками выполнения работ. Конечно, нет серебряной пули, но если вы будете придерживаться определенных принципов, вы не найдете причин для компромисса ни в одном из них.

За последние 10 лет я работал над множеством высококлассных продуктов и имел честь руководить множеством талантливых интерфейсных команд. По большей части это было невероятно вознаграждено, но я также был удостоен награды от высшего руководства за то, что не выполнял «достаточно быстро»!

Вы можете заметить это, обратив внимание на вопросы, которые люди задают регулярно. Слишком много "Есть новости?" или "Есть новости по этому поводу?" обычно это красный флаг. Это может быстро превратиться в «Это занимает слишком много времени» или довольно оскорбительное: «Мы не можем так долго заниматься такими простыми функциями» * дрожь *.

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

Так как же оставаться на вершине производительности и в то же время поддерживать качество? В этой статье я поделюсь некоторыми примерами того, что работает для меня, от сбора требований до обратной связи после развертывания - давайте сделаем это!

Большая картинка

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

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

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

Начнем с самого начала процесса разработки…

В поисках проблемы

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

Чтобы это произошло, нужно всегда не забывать спрашивать «почему?». Рассмотрим следующий разговор:

Хорошо, неделя кажется разумным сроком для обработки, но действительно ли проблема понята? Давайте попробуем еще раз, но обратите внимание, что команда разработчиков спрашивает «почему»:

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

Не говорите «да» на все вопросы и вместо этого постарайтесь понять проблему - ваши технические знания позволят вам найти оптимальное решение.

Клиент на первом месте

Если у вас был достаточный опыт работы с интерфейсами, значит, вы привыкли к тому, что люди думают, что ваша роль - легкая задача. Я уверен, что вы слышали такие вещи, как "Ребята, а вы можете сделать это красивым?" или один из моих личных фаворитов - "А можно просто HTML?" (серьезно, это мне кто-то сказал).

В глазах покупателя внешний интерфейс - это продукт. Думать об этом как о «лизании краски» в последнюю минуту - плохая идея. Если вы хотите хотя бы малейшего шанса на получение хорошего опыта, вам нужно, чтобы все согласились с видением UX / UI в качестве приоритета, и это должно определять каждое техническое решение, которое вы принимаете в дальнейшем.

Вы знаете, что произойдет, если вы начнете с базы данных и позволите ей управлять дизайном интерфейса? В итоге пользовательский интерфейс выглядит как phpMyAdmin - не очень хорошо.

Так что насчет диаграммы архитектуры? Это должно способствовать созданию внешнего интерфейса, верно? Вроде… но, конечно, не само по себе. На самом деле вы хотите, чтобы диаграмма архитектуры была технической реализацией видения UX / UI. Пытаться разработать хорошую архитектуру - пустая трата времени, если вы не знаете, как выглядит продукт с точки зрения потребителя.

Как лучше всего проиллюстрировать видение продукта? Старый добрый макет. А еще лучше - прототип. В идеале привлечь дизайнеров пользовательского интерфейса как можно скорее. В противном случае достаточно карандаша и салфетки.

Думайте прежде всего о покупателях, а оттуда строите в обратном направлении. Постоянное обращение к видению UX / UI будет напоминать вам о том, что важно, поможет вам не сбиться с пути и даст вам больше шансов создать то, чего заслуживают ваши клиенты.

В поисках MVP

Давайте сделаем следующее: MVP (минимально жизнеспособный продукт), вопреки распространенному мнению, не означает предоставление чего-то некачественного. Как раз наоборот - это означает предоставление минимально возможного качества.

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

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

Разбивая задачу на части, делайте истории небольшими, чтобы вы могли быстро доставить что-то ценное. Не тратьте время на приготовление основного блюда, пока покупатель ждет закуски!

Управление ожиданиями

Прошли те времена, когда мы сидели на разноцветных мешках с фасолью, с нетерпением ожидая, что Скрам-мастер сосчитает «3… 2… 1…», прежде чем раскрыть нашу оценку с помощью карты планирования покера (честно говоря, я никогда не осознавал, насколько странно снисходительным была эта церемония, пока Теперь!). Но это хорошая идея, чтобы вместе получить какую-то оценку.

Я знаю, «без оценок», яда-яда-яда, но я не говорю о том, чтобы сообщить дату начала работы или разбить работу на часы. Все, что вам нужно, - это футболка простого размера, чтобы прикрыть спину (футболка? Прикрыть спину? Посмотрите, что я там сделал?). В моей команде мы даем оценку маленьким, средним или большим. Малый - до недели, средний - 1-2 недели, большой - более 2 недель.

Предоставление этой простой информации заранее не позволит людям составить собственные временные рамки и прийти к выводу, что вы слишком медлительны! Это также не дает им подслушивать вас для получения обновлений, давая вам пространство, необходимое для создания чего-то потрясающего.

Изобретая колесо заново

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

Не поймите меня неправильно, я не говорю, что вы должны принимать все, что есть в дикой природе, не задумываясь - я разработчик JavaScript; Я видел чертовски страшное дерьмо на npm, но вы должны следить за тем, что действительно вызывает волну, и относиться к этому серьезно.

Например…

Вы можете создать сложный конвейер развертывания, который волшебным образом разделяет ваш код и развертывает его либо как бессерверные функции, либо как статические файлы с периферии… или просто используйте Vercel и сделайте это одним или двумя щелчками мыши.

Точно так же вы можете создать декларативный, основанный на компонентах, невероятно быстрый движок пользовательского интерфейса… или просто использовать jQuery. Я шучу; прическу! Я, конечно, говорю о React (но используйте все, что поддерживает вашу лодку).

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

Работа в процессе

Ах, пресловутый лимит WIP! Это очень важно и часто упускается из виду - выясните, сколько историй вы хотите вести в данный момент, и придерживайтесь этого.

Я слишком часто встречал ошибку, когда команды думали, что они продуктивны, потому что они работают над 20 разными задачами одновременно, и все они выполнены на 90%. 20 разных вещей при выполнении на 90% по-прежнему ничто в производстве - это буквально ноль для бизнеса.

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

«Проект Феникс» - фантастический роман - объясняет этот принцип лучше, чем я когда-либо мог. Если у вас нет копии, я рекомендую взять ее - оно того стоит!

«Пока код не запущен в производство, ценность фактически не создается, потому что это просто WIP, застрявший в системе». - Проект Феникс, 2013 г.

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

Прекратите вкладывать что-либо в QA

«Готово, только что на стадии контроля качества» - звучит знакомо? Разработчики (в том числе и я) любят это классическое обновление статуса. Подумайте, что это на самом деле означает ...

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

В моей нынешней команде у нас вообще нет столбца на доске для «QA» - вместо этого у нас есть столбец «в процессе», где разработчики и QA-инженеры работают вместе. Это подкрепляет идею о том, что все инженеры несут ответственность за то, чтобы новые функции выходили за рамки возможного.

Лучший способ, который я знаю для реализации этого асинхронного сценария разработки / контроля качества, - это использовать практики разработки на основе магистрали - вероятно, совершенно другой разговор, поэтому я не собираюсь сейчас вдаваться в подробности!

По сути, команда должна обеспечивать качество на протяжении всей разработки функции - контроль качества не является этапом, который нужно выполнять в конце после того, как функция «завершена».

Принимая обратную связь

Хорошие практики непрерывного развертывания позволяют нам постепенно встраивать непосредственно в производственную среду. Этот процесс помогает избежать извечного аргумента «это сработало на моей машине» и в целом делает мир лучше.

Очевидно, почему это хорошая идея по сравнению с реальной архитектурой. Вы не будете строить многоквартирный дом в «тестовом» месте, а затем пытаться переместить всю конструкцию в другое место - это будет безумием!

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

То же самое и с разработкой продукта. Если вы не дадите людям доступ для наблюдения за прогрессом и внесения изменений, вы попадете в эту нелепую фазу «торжественного открытия» ближе к концу проекта, которая гарантированно приведет к двум формам нежелательной обратной связи:

  1. «Обязательно» - когда люди чувствуют необходимость сказать что-то, потому что видят что-то впервые. В итоге они соскребают дно ствола и говорят что-то вроде: «Разве это не должно быть выше сгиба?».
  2. «Полезно, но слишком поздно» - когда люди дают действительно ценные отзывы, но уже слишком поздно для внесения изменений, поэтому вы в конечном итоге откладываете их на этап 2. Предупреждение о спойлере: этап 2 никогда не происходит.

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

Не бойтесь смещения границ - если вы правильно поняли проблему и задокументировали видение UX, вы должны чувствовать себя достаточно уверенно, чтобы принимать отзывы (и действовать в соответствии с ними) на этом пути.

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

Люди делают ошибки. Поэтому разработчики ошибаются. Когда ты выигрываешь или проигрываешь, это ошибка апре-са. - Сэм Кей, «Разработчики - не попадайтесь в эти ловушки

Все мы знаем, что выпуски большого взрыва рискованны, потому что слишком много может пойти не так. Что ж, обратная связь большого взрыва рискованна по той же причине. Своевременная инкрементальная обратная связь позволит вам предоставить более качественный продукт с первого выпуска. Сделайте это - ваши клиенты будут вам благодарны.

Заключение

Короче говоря, возьмите на себя ответственность за весь процесс от запроса до выпуска, думайте в первую очередь о потребителях, избегайте смещения контекста и принимайте раннюю обратную связь. Звучит очевидно, когда вы так говорите! Может быть, это ¯ \ _ (ツ) _ / ¯

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