Почему разработчики должны быть одержимы клиентами

Модели Push and Pull используются в производстве для планирования производства. Эти концепции можно использовать для измерения того, насколько самодостаточной может быть ваша команда разработчиков и насколько глубокой должна быть спецификация вашего программного обеспечения.

Что такое Push или Pull в производстве?

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

Используя вытягивающую модель, у вас будут ежедневные заказы со списком автомобилей, которые должны быть доставлены к концу дня. Что-то вроде 5 автомобилей модели А черного цвета, 3 автомобилей модели А синего цвета, 1 автомобиля модели В кабриолета красного цвета. При этом вам необходимо управлять производственным планом так, чтобы все детали, необходимые для запрошенных автомобилей, выбирались из вашей системы инвентаризации и собирались. Это вытягивание материала из производственной линии.

В производстве вытягивание — это путь и то, как настраиваются сложные процессы «точно вовремя». В оптимальных случаях программное обеспечение для планирования ресурсов предприятия (ERP) подключается от производителя к его поставщикам, а ежедневные партии материалов заказываются в электронном виде.

• Реальность в производстве намного сложнее. Я упрощаю, чтобы подчеркнуть суть.*

Push and pull на самом деле также применяется к разработке программного обеспечения следующим образом:

• Когда функция является просто вариантом использования, и вы позволяете команде разработчиков разработать реализацию, вы получаете детали реализации от команды.

• Когда вы документируете функцию до последней детали, включая макеты, определения API и другие детали, вы доводите детали реализации до команды.

Вот где команда, которая «может думать как пользователь»

может иметь значение.

Почему разработчики должны думать как пользователи?

У меня есть проекты в обеих крайностях. На ум приходит одно воспоминание. Нам пришлось реализовать функцию перехода на летнее время во встроенное потребительское устройство. Это должна была сделать команда в месте, где не используется летнее время. Команда успешно запрограммировала алгоритм високосного года, учитывая сложности каждые 4 года, но не каждые 100, а каждые 400. Они были хорошими и мотивированными разработчиками.

PO и тестировщики сходили с ума, потому что команда работала по принципу "один шаг вперед, два назад" . Ситуация обострилась настолько, что мне пришлось выехать на место в наш центр разработки. Помню, руководитель команды отвел меня в сторонку после обеда и спросил: "Не могли бы вы объяснить мне летнее время?" ЗП предполагал, что если просто написать, что в требованиях все будет ясно.

На море, на берегу и у меня на заднем дворе.

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

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

Итак, вопрос, что вы можете сделать:

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

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

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

Впервые опубликовано здесь