КАК ПОДРУЖИТЬ DISCOVERY И DELIVERY

Конфликт интересов Discovery и Delivery – тема классическая и распространенная. Круче и чаще только конфликт “Продажи vs Производство”. Почему так?

Оба эти этапа, и Discovery, и Delivery, находятся последовательно в одной цепочке производства ценности. И, стало быть, очень сильно зависят друг от друга.

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

Есть еще распространенная фишка, поставить каждому из них свой KPI на Lead Time. И тогда Discovery, лишь бы сделать что-нибудь, отдает побыстрее сырой материал в разработку, а Delivery, понимая все риски для своего Lead Time, долго и нудно не принимает требования и постоянно возвращает обратно в Discovery. Вот так и живем.

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

Как быть? Как по мне, нужно сделать 2 вещи:

1. Формализовать процесс передачи продукта из Discovery в Delivery. Какие-то чеклисты, четкие Definition of Done и т д. Чтобы однозначно было понятно, как должна выглядеть документация и проработка требований, чтобы разработка могла начать ими заниматься

2. Добавить командам какой-то общей мотивации. Внедрить общий KPI. Например, пусть вместе гонятся за единым T2M (Time To Market). Тогда не до ругачек на стыке, иначе премия у всех погорит. При этом, их собственные KPI на Lead Time тоже можно оставить, но мотивацию на них сделать ниже, чем на общий результат. Например, делить премию 30/70 за свои/общие KPI

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

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

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

Что скажете? Согласны с такой идеей? Какие еще есть варианты?