Почему разработчики сопротивляются и даже отказываются добавлять новый функционал с возражениями типа “это невозможно”, “в изначальном ТЗ этого не было”, “мы это не предусмотрели”?
Встречаясь с таким, заказчик постепенно привыкает к мысли о том, что надо изначально делать универсальный функционал, который подойдет под любую ситуацию. Разработчики с радостью берутся такое делать, потому что это означает много интересной работы по моделированию и проектированию всяких разных абстракций без необходимости хоть сколько нибудь сильно погружаться в производственный или бизнесовый контекст.
В итоге, разработка становится очень долгой и затратной. В конечном итоге, когда всё это выходит в прод, оно оказывается практически бесполезным, потому что не решает никакую конкретную задачу. Но ведь именно это разработчиков и просили делать - сделать некий абстрактный функционал, который потом можно будет приспособить под какую-то конкретную задачу.
Суть в том, что абсолютно гибкий функционал создать невозможно. Любая архитектура - это некоторая жесткость, которая принципиально фильтрует набор задач, под который она может быть применена. Как же создать гибкую архитектуру, которую затем достаточно быстро и дешево можно будет дорабатывать?
На самом деле, программный код - это всего лишь часть нормативной документации предприятия. Такой же как, например, должностные и рабочие инструкции сотрудников. И если программный код писать исходя из модели конкретного производственного или бизнес-процесса, то он не будет вступать в серьезный конфликт с любого рода запросами на доработки от владельцев и сотрудников этого самого производства/бизнеса.
Поэтому сначала нужно погрузить разработчиков в существующий производственный или бизнес-процесс, эффективность которого требуется повысить с помощью разработки. Изучение можно останавливать, когда разработчики могут уверенно рассказать о том, как пользователи работают сейчас без будущего функционала продукта. Теперь можно приступать к написанию ТЗ.
Для этого просим разработчиков придумать функционал и опять сводим их с пользователями: разработчики рассказывают/показывают функционал, а пользователи смотрят/слушают и затем рассказывают, как они они будут им пользоваться. Скорее всего там понадобится несколько итераций. Когда мы убедились, что они нашли взаимопонимание, можно фиксировать договоренности документально и приступать к работе.
Встречаясь с таким, заказчик постепенно привыкает к мысли о том, что надо изначально делать универсальный функционал, который подойдет под любую ситуацию. Разработчики с радостью берутся такое делать, потому что это означает много интересной работы по моделированию и проектированию всяких разных абстракций без необходимости хоть сколько нибудь сильно погружаться в производственный или бизнесовый контекст.
В итоге, разработка становится очень долгой и затратной. В конечном итоге, когда всё это выходит в прод, оно оказывается практически бесполезным, потому что не решает никакую конкретную задачу. Но ведь именно это разработчиков и просили делать - сделать некий абстрактный функционал, который потом можно будет приспособить под какую-то конкретную задачу.
Суть в том, что абсолютно гибкий функционал создать невозможно. Любая архитектура - это некоторая жесткость, которая принципиально фильтрует набор задач, под который она может быть применена. Как же создать гибкую архитектуру, которую затем достаточно быстро и дешево можно будет дорабатывать?
На самом деле, программный код - это всего лишь часть нормативной документации предприятия. Такой же как, например, должностные и рабочие инструкции сотрудников. И если программный код писать исходя из модели конкретного производственного или бизнес-процесса, то он не будет вступать в серьезный конфликт с любого рода запросами на доработки от владельцев и сотрудников этого самого производства/бизнеса.
Поэтому сначала нужно погрузить разработчиков в существующий производственный или бизнес-процесс, эффективность которого требуется повысить с помощью разработки. Изучение можно останавливать, когда разработчики могут уверенно рассказать о том, как пользователи работают сейчас без будущего функционала продукта. Теперь можно приступать к написанию ТЗ.
Для этого просим разработчиков придумать функционал и опять сводим их с пользователями: разработчики рассказывают/показывают функционал, а пользователи смотрят/слушают и затем рассказывают, как они они будут им пользоваться. Скорее всего там понадобится несколько итераций. Когда мы убедились, что они нашли взаимопонимание, можно фиксировать договоренности документально и приступать к работе.
Эффективная разработка - это когда проблема заказчика решена с минимальными инвестициями (капитальными затратами) и расходы на владение решением остались в пределах разумного.
Однако, очень часто разработчики пилят то, что вроде бы работает, но проблему по большому счету не решает. Их приходится тыкать во вроде бы очевидные нестыковки, они идут доделывать и переделывать. При этом они сильно демотивируются. Расходы при этом конечно же выше (иногда сильно выше), чем это выглядело при принятии решения на старте разработки. А ещё нередко при этом разработчикам приходится, что называется, костылять и велосипедить, из-за чего вырастает (иногда очень сильно) стоимость всех последующих доработок в связанных компонентах продукта.
Причина в том, что у каждого из участников разработки узкая специализация. Заказчик обладает экспертизой в бизнесе, но он не разбирается в технологиях. Каждый из разработчиков хорошо разбирается в какой-то одной, максимум двух, технологиях, и не разбирается в других. Они все друг друга изначально настолько плохо понимают, что даже избегают общаться напрямую, предпочитая отгораживаться разного рода прокладками в виде тимлидов, техлидов, менеджеров проектов, аналитиков и т.д.
Поэтому очевидное решение - с самого начала ради успеха проекта договариваться напрямую по всем вопросам. Не лениться документировать принятые решения так, чтобы всем участникам, включая заказчика, они были понятны. Однако, такой выход из зоны комфорта требует усилия, и если хотя бы один участник выпадает, или прилагает недостаточно усилий, вышеназванные проблемы не заставят себя долго ждать. Поэтому так важно иметь в команде специально обученного человека, который помогает своевременно договариваться, чтобы ложные ожидания не превращались в проблемы. В англоязычной среде его называют Servant Leader - обслуживающий лидер.
Любой квалифицированный проектный менеджер ведет себя как Servant Leader, выполняя 4 основных роли: ментор, тренер (учитель), фасилитатор и коуч. Если вы хотите подробнее узнать об этих 4 ролях, то для вас я разместил у себя на канале короткий видеоролик буквально на 3 минуты из довольно старого, но до сих пор весьма актуального доклада Асхата Уразбаева "Agile Coach и Scrum Master как руководители нового типа". Приятного просмотра!
Однако, очень часто разработчики пилят то, что вроде бы работает, но проблему по большому счету не решает. Их приходится тыкать во вроде бы очевидные нестыковки, они идут доделывать и переделывать. При этом они сильно демотивируются. Расходы при этом конечно же выше (иногда сильно выше), чем это выглядело при принятии решения на старте разработки. А ещё нередко при этом разработчикам приходится, что называется, костылять и велосипедить, из-за чего вырастает (иногда очень сильно) стоимость всех последующих доработок в связанных компонентах продукта.
Причина в том, что у каждого из участников разработки узкая специализация. Заказчик обладает экспертизой в бизнесе, но он не разбирается в технологиях. Каждый из разработчиков хорошо разбирается в какой-то одной, максимум двух, технологиях, и не разбирается в других. Они все друг друга изначально настолько плохо понимают, что даже избегают общаться напрямую, предпочитая отгораживаться разного рода прокладками в виде тимлидов, техлидов, менеджеров проектов, аналитиков и т.д.
Поэтому очевидное решение - с самого начала ради успеха проекта договариваться напрямую по всем вопросам. Не лениться документировать принятые решения так, чтобы всем участникам, включая заказчика, они были понятны. Однако, такой выход из зоны комфорта требует усилия, и если хотя бы один участник выпадает, или прилагает недостаточно усилий, вышеназванные проблемы не заставят себя долго ждать. Поэтому так важно иметь в команде специально обученного человека, который помогает своевременно договариваться, чтобы ложные ожидания не превращались в проблемы. В англоязычной среде его называют Servant Leader - обслуживающий лидер.
Любой квалифицированный проектный менеджер ведет себя как Servant Leader, выполняя 4 основных роли: ментор, тренер (учитель), фасилитатор и коуч. Если вы хотите подробнее узнать об этих 4 ролях, то для вас я разместил у себя на канале короткий видеоролик буквально на 3 минуты из довольно старого, но до сих пор весьма актуального доклада Асхата Уразбаева "Agile Coach и Scrum Master как руководители нового типа". Приятного просмотра!
YouTube
4 роли Scrum Master и Agile Coach
Полная запись доклада: https://youtu.be/GN5KI4pxwFg?si=-HDfm9pbnuE1RXvz
Когда-то давно, лет 20 назад, я работал инженером в колледже. Мой руководитель узнал о моём сильном желании чего-то разрабатывать и предложил мне написать какую-то программу для учета в учебном процессе. Для этого мне надо было сходить к завучу и выяснить, что именно надо сделать.
Я пришел к завучу и стал спрашивать, как должна выглядеть программа? Какие там должны быть экраны, поля и т.д. И когда завуч сказал, что понятия не имеет, я был в шоке и даже не знал, что спросить. Так мы молча стояли и смотрели друг на друга несколько минут: завуч ждал нормальные вопросы, а я ждал нормальное ТЗ.
Ушел я тогда не солоно хлебавши, думая по молодецкой глупости, что мне просто попался неквалифицированный заказчик. И отчасти, это правда. Есть такое понятие в продажах IT-проектов: квалификация. Продавцы проблематизируют заказчика, чтобы с одной стороны отсеять нецелевого клиента, а с другой стороны получить осмысленный запрос на IT-разработку.
Однако дальше, после квалификации, к заказчику идет аналитик и обычно задает эти самые вопросы в духе "чего изволите". И хорошо, если заказчик честно скажет, что не знает, как было в моём случае. Новичкам, видимо, действительно везёт! Чаще всего заказчик начинает фантазировать, а аналитик всё это тщательно фиксирует, уточняя всё до мелочей и пытаясь выстроить это всё в какую-то непротиворечивую картину и описать в техзадании.
В результате такого подхода всегда получается большое ТЗ и соответственно большой проект. И даже если проектная команда смогла реализовать ТЗ в изначально оговоренный срок и бюджет (почти никогда такое не происходит), есть очень большая вероятность, что заказчик будет разочарован. Да, конечно, умелые продавцы и руководитель проекта натыкают заказчика в ТЗ и убедительно докажут, что тот сам виноват. Но разве такой подход можно назвать профессиональной разработкой?
Никакой заказчик никогда не хочет и не будет хотеть получить то, что написано в ТЗ. Для него функционал продукта - это всегда только расходы. Разовые расходы на переобучение пользователей и постоянные расходы времени самих пользователей на работу с программой. Заказчик хочет получить не функционал, а какой-то бизнес-результат, какое-то изменение в бизнесе за счет переключения пользователей на новый функционал.
Но подход “чего изволите” в процессе анализа в разработке не дает заказчику бизнес-результат. С какого перепугу мы можем рассчитывать получить иной бизнес-результат, не меняя при этом методы и способы его получения? Генри Форд говорил: “Если б я спрашивал у своих клиентов, чего они хотят, я бы сделал быструю лошадь.” Проблема в том, что все хотят изменений, но сами меняться не хотят. Это естественно.
Получается, что подход “чего изволите” сработает только если заказчик уже сам додумался, что надо менять не только и не столько функционал продукта, сколько саму работу пользователей, операционный бизнес-процесс. Такой квалифицированный заказчик оперирует не требованиями, а проблемами или гипотезами получения эффекта от тех или иных изменений в пользовательском опыте своих сотрудников.
Поэтому ключевая функция аналитика в проектной команде не в том, чтобы придумать функционал и расписать его в ТЗ, а в том, чтобы изучить и понять текущий пользовательский опыт, проблемные точки в нём и целевой пользовательский опыт. Требуемый в связи с этим функционал с удовольствием придумают разработчики, а заказчик получит возможность существенно сэкономить время и деньги на решение своих задач.
Есть много разных инструментов, которые может использовать аналитик для того, чтобы выполнить толковый анализ. Один из них - impact mapping. Сначала описываем желаемый для заказчика эффект, затем людей, чей пользовательский опыт надо изменить для получения эффекта, затем гипотезы целевого пользовательского опыта, а самую правую колонку предлагаем заполнить разработчикам - получится бэклог продукта, который при желании можно упаковать в ТЗ.
Я пришел к завучу и стал спрашивать, как должна выглядеть программа? Какие там должны быть экраны, поля и т.д. И когда завуч сказал, что понятия не имеет, я был в шоке и даже не знал, что спросить. Так мы молча стояли и смотрели друг на друга несколько минут: завуч ждал нормальные вопросы, а я ждал нормальное ТЗ.
Ушел я тогда не солоно хлебавши, думая по молодецкой глупости, что мне просто попался неквалифицированный заказчик. И отчасти, это правда. Есть такое понятие в продажах IT-проектов: квалификация. Продавцы проблематизируют заказчика, чтобы с одной стороны отсеять нецелевого клиента, а с другой стороны получить осмысленный запрос на IT-разработку.
Однако дальше, после квалификации, к заказчику идет аналитик и обычно задает эти самые вопросы в духе "чего изволите". И хорошо, если заказчик честно скажет, что не знает, как было в моём случае. Новичкам, видимо, действительно везёт! Чаще всего заказчик начинает фантазировать, а аналитик всё это тщательно фиксирует, уточняя всё до мелочей и пытаясь выстроить это всё в какую-то непротиворечивую картину и описать в техзадании.
В результате такого подхода всегда получается большое ТЗ и соответственно большой проект. И даже если проектная команда смогла реализовать ТЗ в изначально оговоренный срок и бюджет (почти никогда такое не происходит), есть очень большая вероятность, что заказчик будет разочарован. Да, конечно, умелые продавцы и руководитель проекта натыкают заказчика в ТЗ и убедительно докажут, что тот сам виноват. Но разве такой подход можно назвать профессиональной разработкой?
Никакой заказчик никогда не хочет и не будет хотеть получить то, что написано в ТЗ. Для него функционал продукта - это всегда только расходы. Разовые расходы на переобучение пользователей и постоянные расходы времени самих пользователей на работу с программой. Заказчик хочет получить не функционал, а какой-то бизнес-результат, какое-то изменение в бизнесе за счет переключения пользователей на новый функционал.
Но подход “чего изволите” в процессе анализа в разработке не дает заказчику бизнес-результат. С какого перепугу мы можем рассчитывать получить иной бизнес-результат, не меняя при этом методы и способы его получения? Генри Форд говорил: “Если б я спрашивал у своих клиентов, чего они хотят, я бы сделал быструю лошадь.” Проблема в том, что все хотят изменений, но сами меняться не хотят. Это естественно.
Получается, что подход “чего изволите” сработает только если заказчик уже сам додумался, что надо менять не только и не столько функционал продукта, сколько саму работу пользователей, операционный бизнес-процесс. Такой квалифицированный заказчик оперирует не требованиями, а проблемами или гипотезами получения эффекта от тех или иных изменений в пользовательском опыте своих сотрудников.
Поэтому ключевая функция аналитика в проектной команде не в том, чтобы придумать функционал и расписать его в ТЗ, а в том, чтобы изучить и понять текущий пользовательский опыт, проблемные точки в нём и целевой пользовательский опыт. Требуемый в связи с этим функционал с удовольствием придумают разработчики, а заказчик получит возможность существенно сэкономить время и деньги на решение своих задач.
Есть много разных инструментов, которые может использовать аналитик для того, чтобы выполнить толковый анализ. Один из них - impact mapping. Сначала описываем желаемый для заказчика эффект, затем людей, чей пользовательский опыт надо изменить для получения эффекта, затем гипотезы целевого пользовательского опыта, а самую правую колонку предлагаем заполнить разработчикам - получится бэклог продукта, который при желании можно упаковать в ТЗ.
Действительно крутой продукт может сделать только крутая команда. Поэтому, чтобы сделать крутой продукт, нужно собрать крутую команду. Вы тоже так думаете? Тогда у меня для вас плохие новости. Первое утверждение бесспорно, второе утверждение - заблуждение. Но почему-то именно такое заблуждение я нередко встречаю в предпринимательской среде.
Предприниматель мечтает о крутой команде, а собрав выдающихся людей в свою команду, он всячески их удерживает вместе, ожидая от них крутых достижений. Аналогичное заблуждение - в крутой команде работают выдающиеся люди, поэтому надо собрать выдающихся людей, чтобы получить крутую команду.
Для всех подобных убеждений у меня в голове крутится выражение “натягивать сову на глобус”. А когда я вижу активные действия с этими убеждениями, у меня возникает образ попытки гладить кошку против шерсти. И чтоб при этом не страдать от её раздраженных укусов и ударов когтями (разгребать конфликты и закидоны), на руку надевается прочная перчатка-верхонка - наемные менеджеры или недалекие бизнес-партнеры.
Коллеги-предприниматели, я убежден, что это ваша сильная сторона - идти против течения, чтобы делать локальные революции на рынках и отраслях. Но для того, чтобы получить крутую команду, надо делать совсем иные действия. Людьми управляют идеи или деньги. И в зависимости от того, что из этих двух вещей для вас приоритетнее, нужно использовать соответствующий подход к формированию и управлению командой.
Если для вас важнее идея, то вы готовы пойти в менее прибыльную и трудную историю, если это сделает вас ближе к реализации вашего идеала. Конечно, вы понимаете, что нельзя оказать хоть сколько-нибудь масштабное влияние, не найдя прибыльную бизнес-модель. Но деньги для вас всё же вторичны. Вы управляете людьми через идею, и поэтому не испытываете ограничений роста и масштабирования бизнеса.
Если для вас деньги важнее, то ваш подход: “Помоги мне сделать бизнес, и я с тобой поделюсь”. Не надо рассказывать людям о высокой идее, миссии и прочих высоких материях. Будьте честны: вы легко готовы менять идеи ради денег, и это хорошо. Ваша принципиальность не в том, чтобы до конца следовать какому-то идеалу, а в том, чтобы держать своё слово.
Дальше проще. Когда вы правильно привлекаете и мотивируете людей исходя из своих приоритетов, вам уже не нужны выдающиеся люди на старте. Поверьте, что они станут выдающимися, делая вместе с вами ваш продукт. Самые обычные люди, с которыми вы с самого начала установили честные отношения, сработаются друг с другом и станут крутой командой. Нужно только убедиться, что все в команде одинаково понимают задачу и в команде хватает компетенций для её решения.
Общее понимание возникает, когда вы последовательно раскручиваете: цель, видение и план. Интересно, что вы можете ограничиться лишь целью, а видение и план предложить разработать команде, тогда команда будет более самоходной. Цель отвечает на вопрос “зачем”, прозрачно очерчивая командную ответственность за результат. Видение отвечает на вопрос “как”, это своего рода обезличенная схема достижения цели. А план - это конкретные действия конкретных людей в команде.
Чтобы убедиться в наличии компетенций, хорошо подходит формат матрицы, которую можно нарисовать вместе с ранними членами команды - собрались на двоих/троих и нарисовали. По вертикали располагаются имена людей в команде, по горизонтали - необходимые компетенции, на перекрестии - уровень владения.
Дальше прорабатываем риски выпадения членов команды, т.н. bus factor - сколько человек должен сбить автобус, чтобы работа команды остановилась. Делим уровень владения на два (условно “эксперт” и “могу сделать, но не очень хорошо”) и выделяем условное обозначение для “не могу, но хочу научиться”. Такой “экран” наглядно покажет пробелы, узкие места и возможности команды на старте.
Друзья мои, не натягивайте сову на глобус, не питайте ложных ожиданий от людей. Правильно собирайте и честно мотивируйте команду, и пусть у вас всё получится!
Предприниматель мечтает о крутой команде, а собрав выдающихся людей в свою команду, он всячески их удерживает вместе, ожидая от них крутых достижений. Аналогичное заблуждение - в крутой команде работают выдающиеся люди, поэтому надо собрать выдающихся людей, чтобы получить крутую команду.
Для всех подобных убеждений у меня в голове крутится выражение “натягивать сову на глобус”. А когда я вижу активные действия с этими убеждениями, у меня возникает образ попытки гладить кошку против шерсти. И чтоб при этом не страдать от её раздраженных укусов и ударов когтями (разгребать конфликты и закидоны), на руку надевается прочная перчатка-верхонка - наемные менеджеры или недалекие бизнес-партнеры.
Коллеги-предприниматели, я убежден, что это ваша сильная сторона - идти против течения, чтобы делать локальные революции на рынках и отраслях. Но для того, чтобы получить крутую команду, надо делать совсем иные действия. Людьми управляют идеи или деньги. И в зависимости от того, что из этих двух вещей для вас приоритетнее, нужно использовать соответствующий подход к формированию и управлению командой.
Если для вас важнее идея, то вы готовы пойти в менее прибыльную и трудную историю, если это сделает вас ближе к реализации вашего идеала. Конечно, вы понимаете, что нельзя оказать хоть сколько-нибудь масштабное влияние, не найдя прибыльную бизнес-модель. Но деньги для вас всё же вторичны. Вы управляете людьми через идею, и поэтому не испытываете ограничений роста и масштабирования бизнеса.
Если для вас деньги важнее, то ваш подход: “Помоги мне сделать бизнес, и я с тобой поделюсь”. Не надо рассказывать людям о высокой идее, миссии и прочих высоких материях. Будьте честны: вы легко готовы менять идеи ради денег, и это хорошо. Ваша принципиальность не в том, чтобы до конца следовать какому-то идеалу, а в том, чтобы держать своё слово.
Дальше проще. Когда вы правильно привлекаете и мотивируете людей исходя из своих приоритетов, вам уже не нужны выдающиеся люди на старте. Поверьте, что они станут выдающимися, делая вместе с вами ваш продукт. Самые обычные люди, с которыми вы с самого начала установили честные отношения, сработаются друг с другом и станут крутой командой. Нужно только убедиться, что все в команде одинаково понимают задачу и в команде хватает компетенций для её решения.
Общее понимание возникает, когда вы последовательно раскручиваете: цель, видение и план. Интересно, что вы можете ограничиться лишь целью, а видение и план предложить разработать команде, тогда команда будет более самоходной. Цель отвечает на вопрос “зачем”, прозрачно очерчивая командную ответственность за результат. Видение отвечает на вопрос “как”, это своего рода обезличенная схема достижения цели. А план - это конкретные действия конкретных людей в команде.
Чтобы убедиться в наличии компетенций, хорошо подходит формат матрицы, которую можно нарисовать вместе с ранними членами команды - собрались на двоих/троих и нарисовали. По вертикали располагаются имена людей в команде, по горизонтали - необходимые компетенции, на перекрестии - уровень владения.
Дальше прорабатываем риски выпадения членов команды, т.н. bus factor - сколько человек должен сбить автобус, чтобы работа команды остановилась. Делим уровень владения на два (условно “эксперт” и “могу сделать, но не очень хорошо”) и выделяем условное обозначение для “не могу, но хочу научиться”. Такой “экран” наглядно покажет пробелы, узкие места и возможности команды на старте.
Друзья мои, не натягивайте сову на глобус, не питайте ложных ожиданий от людей. Правильно собирайте и честно мотивируйте команду, и пусть у вас всё получится!
Когда я встречаюсь с коллегами по цеху и делюсь с ними своим опытом запуска и поддержки самоорганизованных команд в IT-разработке, то часто слышу скептическое “не верю, так не работает”. Меня пытаются убедить, что разработчики не могут работать без руководителя, это иллюзия. Я понимаю, откуда растут ноги у такого неприятия и с вами с удовольствием поделюсь. Оказывается, есть три уровня управления командами по степени устойчивости в плане предсказуемости.
Первый уровень: микроменеджмент. Руководитель непосредственно каждому раздает задачи, координируя людей в процессе их выполнения, чтобы получить результат для заказчика (бизнеса). На этом уровне оказывается тимлид, который совсем ещё недавно был технарем. Да, это очень просто и эффективно. Бизнесу удобно - всегда есть конкретный человек, который отвечает за всё в команде. Однако устойчивость крайне низкая - всё зависит от одного человека, без которого коммуникация ломается и всё встает колом. Причем заменить его крайне сложно, потому что с новым руководителем весь процесс выстраивается с нуля.
Второй уровень: процессное управление. Руководитель распределяет роли и настраивает операционное взаимодействие между разными участниками в команде так, чтобы результат был получен. На этом уровне работают профессиональные проектные менеджеры. Это сложно, нужна достаточно хорошая квалификация в менеджменте. Однако, даже при наличии таковой, строго регламентированные роли в команде, будучи настроенными вручную с одной стороны ограничивают и демотивируют людей, с другой стороны неизбежно создают дыры в общей зоне ответственности команды. В начале проекта процесс идет бодренько, но ближе к концу проекта скапливаются очереди из вовремя неразрешенных проблем и противоречий между ролями, и проект распухает.
Третий уровень: самоорганизация. Руководитель показывает команде результат, который нужен бизнесу и затем помогает команде самостоятельно договориться по ролям, взаимодействию и необходимой прозрачности процесса. Руководитель всё ещё есть, но его управление становится неявным. Члены команды делают то, что ему нужно, но без его непосредственных предписаний. Роли всё ещё есть, но участники сами их определяют и распределяют между собой. Оказывается, что это крайне сложно для руководителя - требуется хорошая квалификация в менеджменте, коучинге и фасилитации.
Интересно, что внешне работа команды на третьем уровне не отличается от второго уровня. Отличие проявляется в том, как участники реагируют на необходимость перестроиться. На втором уровне это делает руководитель вручную, меняя регламент. На третьем уровне, команда это делает самостоятельно. У меня с этим очень резонирует образ игры на детской площадке, где дети сами распределяют и перераспределяют роли в зависимости от состава и ситуации.
Третий уровень, не смотря на всю сложность достижения, дает бизнесу очень много преимуществ. Например, это очень высокая мотивация членов проектной команды. У меня были реальные случаи, когда люди не уходили из такой команды несмотря на то, что их догоняли рекрутеры из других компаний предлагая сильно больше денег. На мой вопрос “почему” я слышал ответ “нравится атмосфера”, хотя это не был самый лучший офис, техника, не самый крутой проект, и прочее.
Уже даже и речи нет о проблемах коммуникации между членами проектной команды. Необходимое для получения результата общение происходит неформально, почти всегда вовремя и ровно в той степени, какая необходима. Никто не жалуется на скучные ненужные совещания, люди сами определяют необходимый состав собрания и сами контролируют присутствие.
Высокая гибкость процесса и автономность (самоходность). Команда самостоятельно подстраивается под меняющиеся требования, условия, самостоятельно ищет решения для проблем, эскалируя руководителю только внешние. Контроль проекта происходит также без видимого участия руководителя. Члены команды заранее обучаются и подменяют друг друга при выпадении по болезни или отпуска. Они сами контролируют своевременно выполнение задач и указывают друг другу на соответствующие проблемы.
Первый уровень: микроменеджмент. Руководитель непосредственно каждому раздает задачи, координируя людей в процессе их выполнения, чтобы получить результат для заказчика (бизнеса). На этом уровне оказывается тимлид, который совсем ещё недавно был технарем. Да, это очень просто и эффективно. Бизнесу удобно - всегда есть конкретный человек, который отвечает за всё в команде. Однако устойчивость крайне низкая - всё зависит от одного человека, без которого коммуникация ломается и всё встает колом. Причем заменить его крайне сложно, потому что с новым руководителем весь процесс выстраивается с нуля.
Второй уровень: процессное управление. Руководитель распределяет роли и настраивает операционное взаимодействие между разными участниками в команде так, чтобы результат был получен. На этом уровне работают профессиональные проектные менеджеры. Это сложно, нужна достаточно хорошая квалификация в менеджменте. Однако, даже при наличии таковой, строго регламентированные роли в команде, будучи настроенными вручную с одной стороны ограничивают и демотивируют людей, с другой стороны неизбежно создают дыры в общей зоне ответственности команды. В начале проекта процесс идет бодренько, но ближе к концу проекта скапливаются очереди из вовремя неразрешенных проблем и противоречий между ролями, и проект распухает.
Третий уровень: самоорганизация. Руководитель показывает команде результат, который нужен бизнесу и затем помогает команде самостоятельно договориться по ролям, взаимодействию и необходимой прозрачности процесса. Руководитель всё ещё есть, но его управление становится неявным. Члены команды делают то, что ему нужно, но без его непосредственных предписаний. Роли всё ещё есть, но участники сами их определяют и распределяют между собой. Оказывается, что это крайне сложно для руководителя - требуется хорошая квалификация в менеджменте, коучинге и фасилитации.
Интересно, что внешне работа команды на третьем уровне не отличается от второго уровня. Отличие проявляется в том, как участники реагируют на необходимость перестроиться. На втором уровне это делает руководитель вручную, меняя регламент. На третьем уровне, команда это делает самостоятельно. У меня с этим очень резонирует образ игры на детской площадке, где дети сами распределяют и перераспределяют роли в зависимости от состава и ситуации.
Третий уровень, не смотря на всю сложность достижения, дает бизнесу очень много преимуществ. Например, это очень высокая мотивация членов проектной команды. У меня были реальные случаи, когда люди не уходили из такой команды несмотря на то, что их догоняли рекрутеры из других компаний предлагая сильно больше денег. На мой вопрос “почему” я слышал ответ “нравится атмосфера”, хотя это не был самый лучший офис, техника, не самый крутой проект, и прочее.
Уже даже и речи нет о проблемах коммуникации между членами проектной команды. Необходимое для получения результата общение происходит неформально, почти всегда вовремя и ровно в той степени, какая необходима. Никто не жалуется на скучные ненужные совещания, люди сами определяют необходимый состав собрания и сами контролируют присутствие.
Высокая гибкость процесса и автономность (самоходность). Команда самостоятельно подстраивается под меняющиеся требования, условия, самостоятельно ищет решения для проблем, эскалируя руководителю только внешние. Контроль проекта происходит также без видимого участия руководителя. Члены команды заранее обучаются и подменяют друг друга при выпадении по болезни или отпуска. Они сами контролируют своевременно выполнение задач и указывают друг другу на соответствующие проблемы.
Всё ещё есть необходимость решать внешние проблемы, создавать хорошие условия и активно вмешиваться при попытках нарушить границы дозволенного. Нужно периодически организовывать командообразующие мероприятия. Нужно быть готовым к тому, что нельзя просто так нанять и уволить человека без учета мнения такой команды. Нужны значительные усилия по обеспечению прозрачности бизнес-запроса, целей разработки. Наконец, нужно очень много терпения руководителя, потому что на пути к третьему уровню команда будет много раз ошибаться, чтобы научиться.
Как этому научиться? Нужно признать, что это возможно и захотеть перейти на третий уровень - пожалуй, это самое сложное. Нужно быть действительно экспертом в проектном менеджменте, чтобы по существу отвечать команде на вопросы и быть способным вместе с ними находить необычные приемы по части самоуправления. Очертите границы, за которые команда не должна переходить в своих экспериментах, сделайте их прозрачными и сохраните за собой право применять административный ресурс на этот случай.
Кажется, что я не смогу описать всё, что нужно для этого в тесных рамках одного поста. Но для этого я собственно и завел этот канал, чтобы делиться с вами, выпуская один пост за другим, когда появляется возможность. Оставайтесь на связи!
Как этому научиться? Нужно признать, что это возможно и захотеть перейти на третий уровень - пожалуй, это самое сложное. Нужно быть действительно экспертом в проектном менеджменте, чтобы по существу отвечать команде на вопросы и быть способным вместе с ними находить необычные приемы по части самоуправления. Очертите границы, за которые команда не должна переходить в своих экспериментах, сделайте их прозрачными и сохраните за собой право применять административный ресурс на этот случай.
Кажется, что я не смогу описать всё, что нужно для этого в тесных рамках одного поста. Но для этого я собственно и завел этот канал, чтобы делиться с вами, выпуская один пост за другим, когда появляется возможность. Оставайтесь на связи!
Основатель бизнеса знает и может организовать всё в своём бизнесе: и маркетинг, и продажи, и производство. Иначе есть риск, что бизнес придется закрыть при уходе сотрудника-носителя уникального знания. Но IT-разработка всегда будет находиться в слепой зоне у основателей по одной простой причине: слишком сложно.
Технический директор, который создал минимально-необходимую автоматизацию на старте, не спасает. Потому что IT-инфраструктура предприятия сильно разрастается и уже невозможно совместить в одном человеке все необходимые компетенции с достаточной глубиной для снижения зависимости от наемных сотрудников. Более того, обычно хороший технарь - плохой менеджер.
И поэтому часто бывает, что сроки по выпуску нужного бизнесу функционала сильно просрочены или сделали совсем не то, что нужно для бизнеса, но абсолютно невозможно найти ни виноватых, ни причину происходящего. Случалось вам наблюдать такое?
Предприниматель начинает искать схемы давления на IT-отдел, чтобы хоть как-то заставить их работать на результат. Но это всегда заканчивается плохо. Падает качество, разработчики начинают выкручивать руки - просить повышения не за достижения, а чтоб хуже не стало. Появляется система бесконечных согласований, как способ ухода от ответственности. Отношения с техническим директором портятся, а уволить его реально страшно. Как вам зарплата техдира в 700 тыс руб при его практически нулевой ответственности за бизнес-результат? И это реальный пример.
Дело в том, что реальная причина - сломанный телефон между владельцем IT-продукта и разработчиками этого IT-продукта. Низкий уровень доверия между бизнесом и разработкой приводит к тому, что разные выделенные роли обдирают команду, забирая ответственность. Аналитик, тимлид, менеджер проекта, архитектор - все эти ребята оставляют команде только одно: писать код. В этой системе нет ни одного человека, который бы персонально отвечал за бизнес-результат.
Но у нас Agile! В каждой команде разработчиков есть Product Owner. Значит причина в чем-то другом, скажете вы. Давайте разберемся, кто такой владелец продукта. Это сотрудник компании, который отвечает за какую-то функцию, выполнение которой требует автоматизации. Например, владельцем продукта “1С Бухгалтерия” является главбух, владельцем CRM-системы - руководитель отдела продаж.
Представьте прямо сейчас тот функционал продукта, с разработкой которого у вас возникают проблемы. И дайте себе ответы, только честно. Какой бизнес-результат нельзя получить без него? Кто отвечает за этот бизнес-результат? Кто в иерархии находится между ним и разработчиками? Роли всех этих людей - причина ваших проблем с этим функционалом. Мы вроде бы нанимали в штат профессионалов, которые должны работать на бизнес-результат, но получили в штате безответственных узких специалистов, которые могут только писать код.
Решение в том, чтобы радикально сблизить бизнес и разработку, передать ответственность за бизнес-результат в команду разработки. В отличие от проектного аутсорсинга разработки, здесь нет реальных причин для низкого доверия. Для владельца IT-продукта это означает выйти из зоны комфорта и стать частью IT-команды на время разработки соответствующего функционала.
Но надо быть готовым к текучке кадров. В результате длительного существования иерархии в разработке остаются только такие разработчики, которым не хочется отвечать ни за что, кроме “своей” работы - писать код. Люди начнут увольняться, надо будет набирать других.
Также надо быть готовым к открытому и скрытому саботажу. Если поменять роли, но оставить людей, то эффект выученной беспомощности сведет на нет все ваши усилия по орг трансформации. Нужен профессиональный Agile-коуч или Scrum Master, который поможет вам правильно измерить и проконтролировать необходимый бизнес-эффект от орг изменений.
Технический директор, который создал минимально-необходимую автоматизацию на старте, не спасает. Потому что IT-инфраструктура предприятия сильно разрастается и уже невозможно совместить в одном человеке все необходимые компетенции с достаточной глубиной для снижения зависимости от наемных сотрудников. Более того, обычно хороший технарь - плохой менеджер.
И поэтому часто бывает, что сроки по выпуску нужного бизнесу функционала сильно просрочены или сделали совсем не то, что нужно для бизнеса, но абсолютно невозможно найти ни виноватых, ни причину происходящего. Случалось вам наблюдать такое?
Предприниматель начинает искать схемы давления на IT-отдел, чтобы хоть как-то заставить их работать на результат. Но это всегда заканчивается плохо. Падает качество, разработчики начинают выкручивать руки - просить повышения не за достижения, а чтоб хуже не стало. Появляется система бесконечных согласований, как способ ухода от ответственности. Отношения с техническим директором портятся, а уволить его реально страшно. Как вам зарплата техдира в 700 тыс руб при его практически нулевой ответственности за бизнес-результат? И это реальный пример.
Дело в том, что реальная причина - сломанный телефон между владельцем IT-продукта и разработчиками этого IT-продукта. Низкий уровень доверия между бизнесом и разработкой приводит к тому, что разные выделенные роли обдирают команду, забирая ответственность. Аналитик, тимлид, менеджер проекта, архитектор - все эти ребята оставляют команде только одно: писать код. В этой системе нет ни одного человека, который бы персонально отвечал за бизнес-результат.
Но у нас Agile! В каждой команде разработчиков есть Product Owner. Значит причина в чем-то другом, скажете вы. Давайте разберемся, кто такой владелец продукта. Это сотрудник компании, который отвечает за какую-то функцию, выполнение которой требует автоматизации. Например, владельцем продукта “1С Бухгалтерия” является главбух, владельцем CRM-системы - руководитель отдела продаж.
Представьте прямо сейчас тот функционал продукта, с разработкой которого у вас возникают проблемы. И дайте себе ответы, только честно. Какой бизнес-результат нельзя получить без него? Кто отвечает за этот бизнес-результат? Кто в иерархии находится между ним и разработчиками? Роли всех этих людей - причина ваших проблем с этим функционалом. Мы вроде бы нанимали в штат профессионалов, которые должны работать на бизнес-результат, но получили в штате безответственных узких специалистов, которые могут только писать код.
Решение в том, чтобы радикально сблизить бизнес и разработку, передать ответственность за бизнес-результат в команду разработки. В отличие от проектного аутсорсинга разработки, здесь нет реальных причин для низкого доверия. Для владельца IT-продукта это означает выйти из зоны комфорта и стать частью IT-команды на время разработки соответствующего функционала.
Но надо быть готовым к текучке кадров. В результате длительного существования иерархии в разработке остаются только такие разработчики, которым не хочется отвечать ни за что, кроме “своей” работы - писать код. Люди начнут увольняться, надо будет набирать других.
Также надо быть готовым к открытому и скрытому саботажу. Если поменять роли, но оставить людей, то эффект выученной беспомощности сведет на нет все ваши усилия по орг трансформации. Нужен профессиональный Agile-коуч или Scrum Master, который поможет вам правильно измерить и проконтролировать необходимый бизнес-эффект от орг изменений.
Очень часто встречается мнение, что с разработчиками бесполезно разговаривать о бизнесе. Они технари, ничего в этом не понимают и поэтому нужны переводчики с языка бизнеса на технический язык: бизнес-аналитик, системный аналитик, архитектор, тимлид, менеджер проекта, технический писатель. Но что, если вы - малый бизнес, который взял в штат 2-3 разработчика? Нанимать к ним людей, которые будут играть вышеперечисленные роли кажется абсурдом.
Более того, даже в крупных организациях масштабирование разработки всё чаще и чаще идет не в сторону усиления иерархии, а горизонтально. Всё дело в координационных издержках, которые несет бизнес при коммуникации с разработчиками через всю эту вертикальную конструкцию. Короче, весь этот перевод с бизнесового языка на технический обходится слишком долго и дорого при любом масштабе.
Выход из ситуации в том, чтобы отказаться от посредников совсем и наладить коммуникацию между бизнесом и разработкой напрямую. Буквально это означает:
✍️ отказаться от функционального деления команд и перевести их в кросс-функциональные
✍️ организовать регулярное общение между разработчиками и пользователями - операционными сотрудниками бизнеса, партнерами, клиентами
✍️ включить в это общение сотрудника, который принимает бизнес-решения в разработке
Однако, при попытке наладить такое общение, возникают проблемы. И одна из них: разработчики задают тупые вопросы, из-за чего бизнес тратит много времени на лишние разговоры и разработчики при этом всё равно умудряются забыть запилить что-то важное или запилить не то, что их просили. Та самая проблема, которая отлично решается с помощью вышеупомянутой вертикали, иерархии переводчиков с языка бизнеса на язык технарей.
Как надо налаживать коммуникацию, чтобы за минимальное время договариваться с разработчиками и при этом результат соответствовал ожиданиям?
Трудный ответ для тех, кто хочет попробовать сам. Разработчики должны фокусироваться не на том, чтобы пилить функционал, а на том, чтобы помогать бизнесу решать его бизнесовые, операционные задачи. Поэтому, при обсуждении всяких запросов на разработку, надо обсуждать и записывать в тикет-систему (Jira, Kaiten и т.п.) в первую очередь эти самые бизнесовые задачи, выполняемые бизнесом операции, и уже во-вторую очередь, требуемый для этого функционал.
Например, когда бизнесу надо запилить отчет, то самый первый вопрос - кто и в каких ситуациях будет пользоваться этим отчетом? Эти use-кейсы применяются в разработке для тестирования, чтобы убедиться в готовности функционала к проду. Когда у разработчиков есть понимание use-кейсов, они сами предложат требования к отчету в виде шапки с полями и т.п. - бизнесу уже не надо тратить время, чтобы придумывать и разжевывать эти детали.
В целом, таких нюансов довольно много. Поэтому простой ответ: привлечь Agile-коуча к работе с организацией. 90% его усилий будет связано именно с бизнесом, а не с разработкой. На выходе вы получите легковесный процесс разработки, который обладает достаточной прозрачностью и предсказуемостью.
Если вы хотите прокачать навык Agile-коучинга в себе или прокачать своего сотрудника, то я могу порекомендовать курсы ребят из scrum.ru, за остальных не ручаюсь - на рынке много ложного знания про Agile. Рибейт они мне не платят, если что). Поэтому можете не ссылаться на меня, когда пойдете учиться к ним. А ещё приходите в личку - я могу взять на менторинг.
Более того, даже в крупных организациях масштабирование разработки всё чаще и чаще идет не в сторону усиления иерархии, а горизонтально. Всё дело в координационных издержках, которые несет бизнес при коммуникации с разработчиками через всю эту вертикальную конструкцию. Короче, весь этот перевод с бизнесового языка на технический обходится слишком долго и дорого при любом масштабе.
Выход из ситуации в том, чтобы отказаться от посредников совсем и наладить коммуникацию между бизнесом и разработкой напрямую. Буквально это означает:
✍️ отказаться от функционального деления команд и перевести их в кросс-функциональные
✍️ организовать регулярное общение между разработчиками и пользователями - операционными сотрудниками бизнеса, партнерами, клиентами
✍️ включить в это общение сотрудника, который принимает бизнес-решения в разработке
Однако, при попытке наладить такое общение, возникают проблемы. И одна из них: разработчики задают тупые вопросы, из-за чего бизнес тратит много времени на лишние разговоры и разработчики при этом всё равно умудряются забыть запилить что-то важное или запилить не то, что их просили. Та самая проблема, которая отлично решается с помощью вышеупомянутой вертикали, иерархии переводчиков с языка бизнеса на язык технарей.
Как надо налаживать коммуникацию, чтобы за минимальное время договариваться с разработчиками и при этом результат соответствовал ожиданиям?
Трудный ответ для тех, кто хочет попробовать сам. Разработчики должны фокусироваться не на том, чтобы пилить функционал, а на том, чтобы помогать бизнесу решать его бизнесовые, операционные задачи. Поэтому, при обсуждении всяких запросов на разработку, надо обсуждать и записывать в тикет-систему (Jira, Kaiten и т.п.) в первую очередь эти самые бизнесовые задачи, выполняемые бизнесом операции, и уже во-вторую очередь, требуемый для этого функционал.
Например, когда бизнесу надо запилить отчет, то самый первый вопрос - кто и в каких ситуациях будет пользоваться этим отчетом? Эти use-кейсы применяются в разработке для тестирования, чтобы убедиться в готовности функционала к проду. Когда у разработчиков есть понимание use-кейсов, они сами предложат требования к отчету в виде шапки с полями и т.п. - бизнесу уже не надо тратить время, чтобы придумывать и разжевывать эти детали.
В целом, таких нюансов довольно много. Поэтому простой ответ: привлечь Agile-коуча к работе с организацией. 90% его усилий будет связано именно с бизнесом, а не с разработкой. На выходе вы получите легковесный процесс разработки, который обладает достаточной прозрачностью и предсказуемостью.
Если вы хотите прокачать навык Agile-коучинга в себе или прокачать своего сотрудника, то я могу порекомендовать курсы ребят из scrum.ru, за остальных не ручаюсь - на рынке много ложного знания про Agile. Рибейт они мне не платят, если что). Поэтому можете не ссылаться на меня, когда пойдете учиться к ним. А ещё приходите в личку - я могу взять на менторинг.
Когда бизнес в лице операционных сотрудников спрашивает "когда будет готова такая-то фича", мы даем оценку по сложности - легко, средне-сложно, сложно (S, M, L). Однако, от нас хотят именно срок. И часто его хотят явно для того, чтобы потом прийти и потребовать попасть в него. Это называется дедлайн. Сделай или умри. И ладно, если это внешний дедлайн, такое действительно бывает. Но часто это просто способ заставить работать быстрее, чем это реально возможно.
Можно ли давать срок? Ведь мы рискуем в него не попасть, потому что разработка - это всегда работа с некоторой степенью сложности/запутанности и поэтому в некоторой степени непредсказуема. Много сложности = слабо предсказуемо. Мало сложности = предсказуемо, но всё ещё есть риски не попасть.
Если мы поддаемся на давление и даем срок, то интуитивно даем его с малой или большой долей подстраховки. Но по первому закону Паркинсона с каждым разом, когда мы даем срок с подстраховкой, она вырастает всё больше и больше, делая in-house разработку невыгодной, а разработчиков в глазах бизнеса - ленивыми паразитами.
Чтобы этого не происходило, мы никогда не даем срок. Мы даем прогноз. Как в медицине. Медики никогда ничего не обещают, по одной простой причине - слишком сложная, запутанная область деятельности. Там слишком много разных факторов, чтобы их в принципе можно было все учесть. Поэтому всегда есть некоторая вероятность - либо большая, либо маленькая.
Поэтому никто в медицине не пытается взять обязательство с медиков. А те кто пытается, встречает решительный отпор: "Мы не даем обещаний, только прогнозы." Однако, медиков постоянно проверяют, дисциплинируют, обучают, держат стандарты высокими, а ещё заставляют давать клятву Гиппократа и искренне ей следовать. И никто не смеется над ними. Напротив, чуть чего, мы бежим к ним за помощью. Потому что выхода другого нет.
Также и в разработке. Мы не даем никаких обещаний, и тем более не даем ставить искусственные дедлайны. Только прогнозы. Потому что разработка - это слишком сложная сфера деятельности. Там слишком много разных вводных, большая степень запутанности.
Однако, мы постоянно прилагаем усилия к совершенствованию процесса разработки и изучаем передовые технологии организации процесса, чтобы повысить скорость и предсказуемость поставки функционала. Мы постоянно изучаем и внедряем инженерные практики, разрабатываем стандарты и тщательно следим за их соблюдением, чтобы повысить качество и снизить дефектность функционала. Мы постоянно проясняем реальные потребности бизнеса и ищем самые простые и короткие пути решения. И мы серьезно относимся к разного рода эмоциональным упражнениям на ретроспективе, потому что это реально помогает поддерживать и развивать ценность разработки для бизнеса.
Можно ли давать срок? Ведь мы рискуем в него не попасть, потому что разработка - это всегда работа с некоторой степенью сложности/запутанности и поэтому в некоторой степени непредсказуема. Много сложности = слабо предсказуемо. Мало сложности = предсказуемо, но всё ещё есть риски не попасть.
Если мы поддаемся на давление и даем срок, то интуитивно даем его с малой или большой долей подстраховки. Но по первому закону Паркинсона с каждым разом, когда мы даем срок с подстраховкой, она вырастает всё больше и больше, делая in-house разработку невыгодной, а разработчиков в глазах бизнеса - ленивыми паразитами.
Чтобы этого не происходило, мы никогда не даем срок. Мы даем прогноз. Как в медицине. Медики никогда ничего не обещают, по одной простой причине - слишком сложная, запутанная область деятельности. Там слишком много разных факторов, чтобы их в принципе можно было все учесть. Поэтому всегда есть некоторая вероятность - либо большая, либо маленькая.
Поэтому никто в медицине не пытается взять обязательство с медиков. А те кто пытается, встречает решительный отпор: "Мы не даем обещаний, только прогнозы." Однако, медиков постоянно проверяют, дисциплинируют, обучают, держат стандарты высокими, а ещё заставляют давать клятву Гиппократа и искренне ей следовать. И никто не смеется над ними. Напротив, чуть чего, мы бежим к ним за помощью. Потому что выхода другого нет.
Также и в разработке. Мы не даем никаких обещаний, и тем более не даем ставить искусственные дедлайны. Только прогнозы. Потому что разработка - это слишком сложная сфера деятельности. Там слишком много разных вводных, большая степень запутанности.
Однако, мы постоянно прилагаем усилия к совершенствованию процесса разработки и изучаем передовые технологии организации процесса, чтобы повысить скорость и предсказуемость поставки функционала. Мы постоянно изучаем и внедряем инженерные практики, разрабатываем стандарты и тщательно следим за их соблюдением, чтобы повысить качество и снизить дефектность функционала. Мы постоянно проясняем реальные потребности бизнеса и ищем самые простые и короткие пути решения. И мы серьезно относимся к разного рода эмоциональным упражнениям на ретроспективе, потому что это реально помогает поддерживать и развивать ценность разработки для бизнеса.
Выделенные роли в команде разработки создают непреодолимые проблемы. Например, бэкэндер, фронтэндер, тестировщик и т.д. Потому что единственная реальная мера прогресса в разработке - это работающий готовый к релизу функционал.
Бизнесу не нужен рабочий backend, frontend, качественно написанные багрепорты, автотесты, и т.п. Ему нужен работающий готовый к релизу функционал. И если в производстве можно отладить каждый шаг и промежуточный результат, то в разработке нельзя. Производство - это набор одинаковых операций и результатов, а разработка каждый раз выдает разный результат.
Казалось бы, давайте заранее создадим необходимую определенность и точность. Все детально спроектируем и напишем ТЗ: все промежуточные результаты, сущности и т.д. Но даже если упороться и выкинуть много времени и денег на предварительную аналитику и проектирование, это будет максимум 80% определенности. Все равно остаётся запрос на творчество. 100% будет только после завершения разработки.
Именно поэтому выделение ролей за разные компоненты и функции в разработке дает неожиданные и неприятные эффекты. Например, если в производстве попытаться "улучшить" какую-то фазу процесса, не понимая, как работает весь конвейер, продукция на выходе может перестать выполнять свою функцию, а может и того хуже - покалечить кого нибудь. Вносить изменения в продакшн (!) может только тот человек, который видит и знает весь конвейер целиком.
Я ни разу не видел человека, отлично знающего весь стэк технологий какого-то IT-продукта. Любой тимлид с единоличной ответственностью за результат разработки неизбежно размывает свою экспертизу по всему стэку. Получается поверхностное знание каждой технологии. А у подчиненных ответственность сужается до уровня роли, которую каждому выделил тимлид.
В результате, тимлид отвечает за то, что практически не может контролировать. Его решения будут далеки от оптимальных. Кроме того, он становится незаменимым - без него работа встает колом. Ни в отпуск не уйти, ни заболеть, ни уволиться. Его подчиненные, кстати, в этом случае тоже становятся незаменимыми. Кроме того, он становится узким местом коммуникации, из-за которого в разработке неизбежно растет размер партии и, как следствие, растут косяки, ошибки, просчеты, особенно, интеграционные. В итоге тимлид непременно облажается, вопрос времени.
Да, проектный менеджмент все таки применяют для решения этих проблем. Когда менеджмент сильно растет по ролям: архитектор, тимлид на каждую функцию, техлид на каждый компонент, и т.д. Но мы уверены, что хотим раздувать расходы на разработку только потому, что не хочется выходить за рамки искусственной роли?
Другое дело, что убирая тимлида и размазывая ответственность на всю команду, инерция мышления "я бэкэндер", "я фронтэндер" и т.д. - ещё сильнее усугубляет ситуацию, и может понадобится много времени для преодоления этих "ярлыков". Однако, это возможно. И это не значит, что все теперь должны потерять узкую специализацию и стать универсалами. Экспертиза и ответственность - это про разное. И тем более не значит, что теперь не будет лидеров. Наоборот, следует поощрять ситуационное лидерство в команде. Проблемы создают роли, назначенные сверху.
И если у команд есть свобода принятия организационных решений, то вы увидите, как сильно изменится эффективность разработки, а вместе с ней и мотивация, и атмосфера. Процесс становится подобен игре на спортивной площадке: люди сами распределяют между собой роли, в зависимости от ситуации, и также при изменении игровой ситуации оперативно перераспределяют эти роли, замещая и подстраховывая друг друга.
Бизнесу не нужен рабочий backend, frontend, качественно написанные багрепорты, автотесты, и т.п. Ему нужен работающий готовый к релизу функционал. И если в производстве можно отладить каждый шаг и промежуточный результат, то в разработке нельзя. Производство - это набор одинаковых операций и результатов, а разработка каждый раз выдает разный результат.
Казалось бы, давайте заранее создадим необходимую определенность и точность. Все детально спроектируем и напишем ТЗ: все промежуточные результаты, сущности и т.д. Но даже если упороться и выкинуть много времени и денег на предварительную аналитику и проектирование, это будет максимум 80% определенности. Все равно остаётся запрос на творчество. 100% будет только после завершения разработки.
Именно поэтому выделение ролей за разные компоненты и функции в разработке дает неожиданные и неприятные эффекты. Например, если в производстве попытаться "улучшить" какую-то фазу процесса, не понимая, как работает весь конвейер, продукция на выходе может перестать выполнять свою функцию, а может и того хуже - покалечить кого нибудь. Вносить изменения в продакшн (!) может только тот человек, который видит и знает весь конвейер целиком.
Я ни разу не видел человека, отлично знающего весь стэк технологий какого-то IT-продукта. Любой тимлид с единоличной ответственностью за результат разработки неизбежно размывает свою экспертизу по всему стэку. Получается поверхностное знание каждой технологии. А у подчиненных ответственность сужается до уровня роли, которую каждому выделил тимлид.
В результате, тимлид отвечает за то, что практически не может контролировать. Его решения будут далеки от оптимальных. Кроме того, он становится незаменимым - без него работа встает колом. Ни в отпуск не уйти, ни заболеть, ни уволиться. Его подчиненные, кстати, в этом случае тоже становятся незаменимыми. Кроме того, он становится узким местом коммуникации, из-за которого в разработке неизбежно растет размер партии и, как следствие, растут косяки, ошибки, просчеты, особенно, интеграционные. В итоге тимлид непременно облажается, вопрос времени.
Да, проектный менеджмент все таки применяют для решения этих проблем. Когда менеджмент сильно растет по ролям: архитектор, тимлид на каждую функцию, техлид на каждый компонент, и т.д. Но мы уверены, что хотим раздувать расходы на разработку только потому, что не хочется выходить за рамки искусственной роли?
Другое дело, что убирая тимлида и размазывая ответственность на всю команду, инерция мышления "я бэкэндер", "я фронтэндер" и т.д. - ещё сильнее усугубляет ситуацию, и может понадобится много времени для преодоления этих "ярлыков". Однако, это возможно. И это не значит, что все теперь должны потерять узкую специализацию и стать универсалами. Экспертиза и ответственность - это про разное. И тем более не значит, что теперь не будет лидеров. Наоборот, следует поощрять ситуационное лидерство в команде. Проблемы создают роли, назначенные сверху.
И если у команд есть свобода принятия организационных решений, то вы увидите, как сильно изменится эффективность разработки, а вместе с ней и мотивация, и атмосфера. Процесс становится подобен игре на спортивной площадке: люди сами распределяют между собой роли, в зависимости от ситуации, и также при изменении игровой ситуации оперативно перераспределяют эти роли, замещая и подстраховывая друг друга.
Если в проектах по IT-разработке не контролировать работу каждого, то происходит дичь. Надо перепроверять за аналитиками, разработчиками и QA согласованность их работ между собой. Потому что у них, как выразился мой знакомый техдир, тотальное безразличие к общему результату. Все хотят выделить свою личную зону ответственности, которая прописана в виде формального документа/карточки, и спокойно работать. Когда вылазит неопределенность, неизвестность в задаче - они останавливаются и отписываются своему начальнику (РП, лиду, и т.п.), чтоб он все согласовал и решил эту проблему, и они спокойно продолжили работать.
Тимлиды не могут помочь практически никак. Так как чтобы проконтролировать правильность выполнения работ отдельной взятой функцией, надо убедиться в согласованности этих работ с работами, которые делаются в других функциях. А для этого надо вгрузить в голову весь проект. Тимлид, который априори отвечает за отдельную функцию в 5-10-15-ти проектах, не может и не будет это делать, потому что он отвечает только за свою функцию.
В качестве решения используется интеграционная роль, которая отвечает за интеграцию работ разных функций в общий результат для заказчика. РП, техлид, техдир и т.д. Сколько одновременно проектов они могут держать в своих головах? 2,3,5? Кажется, что это какой-то титанический труд, таскать в голове такое. Какое-то лютое издевательство над людьми. К тому же людей, способных держать в голове 2-3 проекта с вышеописанными мелочами и ещё с достаточной энергией, чтобы всех контролировать, очень трудно найти и нанять. А ещё труднее проконтролировать, что они сознательные, что они действительно это делают. Не получится такое масштабировать.
Кросс-функциональная команда решает эту проблему в корне. Каждый разработчик, который работает full time на проекте, спокойно вгружает весь проект в голову и работает. Это нормально, потому что иначе он не напишет хороший код, документацию, тестовый артефакт и т.п. Ему мешает только то, что он part-time на многих проектах. А part-time он потому, что у него есть своя узкая специализация, которая жестко сцеплена с его ролью, ответственностью на всех проектах. И на основе этой жесткой сцепки выстроена вся проектная организация по разработке.
Кроме этого, командной работе мешает то, что заказчик не хочет быть частью команды. Он думает, что аналитик, которому он надиктует свои хотелки, как-то сведет всё в целостную картинку и проконтролирует, что там нет когнитивных искажений и противоречий как в самом документе, так и с процессом будущего внедрения и использования этого всего. Это же иллюзия. Внушительный документ в 50-100-200 страниц, напичканный красивыми картинками, диаграммами и умными словами, никак не гарантирует целостность и реализуемость их хотелок.
Что тут делать? Риски облажаться очень большие. По факту лажа просто неизбежна. И помочь может только одно: разрешить себе ошибаться. И раз ошибки неизбежны, то ошибаться как можно быстрее. Это значит, резать релизы до 1-2 недель, максимум 1 месяц. Никаких длинных забегов. Чтобы лажа вылазила как можно раньше и у нас вместе с заказчиком было ещё достаточно времени и денег, чтобы её исправлять. Большинство проектов по IT-разработке прекрасно разбиваются на такие короткие забеги. И это сработает, потому что все вышеописанные проблемы не позволят коротко бегать. Организация, настроенная на длинные забеги, будет умолять вернуть назад длинные забеги. Надо только заручиться поддержкой на самом верху и не сдаваться.
Тимлиды не могут помочь практически никак. Так как чтобы проконтролировать правильность выполнения работ отдельной взятой функцией, надо убедиться в согласованности этих работ с работами, которые делаются в других функциях. А для этого надо вгрузить в голову весь проект. Тимлид, который априори отвечает за отдельную функцию в 5-10-15-ти проектах, не может и не будет это делать, потому что он отвечает только за свою функцию.
В качестве решения используется интеграционная роль, которая отвечает за интеграцию работ разных функций в общий результат для заказчика. РП, техлид, техдир и т.д. Сколько одновременно проектов они могут держать в своих головах? 2,3,5? Кажется, что это какой-то титанический труд, таскать в голове такое. Какое-то лютое издевательство над людьми. К тому же людей, способных держать в голове 2-3 проекта с вышеописанными мелочами и ещё с достаточной энергией, чтобы всех контролировать, очень трудно найти и нанять. А ещё труднее проконтролировать, что они сознательные, что они действительно это делают. Не получится такое масштабировать.
Кросс-функциональная команда решает эту проблему в корне. Каждый разработчик, который работает full time на проекте, спокойно вгружает весь проект в голову и работает. Это нормально, потому что иначе он не напишет хороший код, документацию, тестовый артефакт и т.п. Ему мешает только то, что он part-time на многих проектах. А part-time он потому, что у него есть своя узкая специализация, которая жестко сцеплена с его ролью, ответственностью на всех проектах. И на основе этой жесткой сцепки выстроена вся проектная организация по разработке.
Кроме этого, командной работе мешает то, что заказчик не хочет быть частью команды. Он думает, что аналитик, которому он надиктует свои хотелки, как-то сведет всё в целостную картинку и проконтролирует, что там нет когнитивных искажений и противоречий как в самом документе, так и с процессом будущего внедрения и использования этого всего. Это же иллюзия. Внушительный документ в 50-100-200 страниц, напичканный красивыми картинками, диаграммами и умными словами, никак не гарантирует целостность и реализуемость их хотелок.
Что тут делать? Риски облажаться очень большие. По факту лажа просто неизбежна. И помочь может только одно: разрешить себе ошибаться. И раз ошибки неизбежны, то ошибаться как можно быстрее. Это значит, резать релизы до 1-2 недель, максимум 1 месяц. Никаких длинных забегов. Чтобы лажа вылазила как можно раньше и у нас вместе с заказчиком было ещё достаточно времени и денег, чтобы её исправлять. Большинство проектов по IT-разработке прекрасно разбиваются на такие короткие забеги. И это сработает, потому что все вышеописанные проблемы не позволят коротко бегать. Организация, настроенная на длинные забеги, будет умолять вернуть назад длинные забеги. Надо только заручиться поддержкой на самом верху и не сдаваться.
Как сжечь 100-200 млн руб на разработку?
Один подход, чтобы не сжечь впустую: тщательный подбор подрядчика, PMO и тщательно проработанное ТЗ. Другой подход - работать "по аджайлу": кросс-функциональная команда in-house, которая выдает на демо кусочек скоупа работ каждый спринт. Однако, оба подхода приводят к бестолковому сливу бюджета на разработку. На моем опыте сливали ~25, 90 и даже 250 млн руб.
Конечно, это я слегка приукрасил. Их не потеряли. За них получили удобные функциональные приложения. Однако, проблема в том, что условный ген дир, который заказывал музыку, потерял надежду и перекрыл финансирование, перевел их на техподдержку.
Почему? Этот ген дир ожидал какую-то бизнес-динамику от этих приложений. Поэтому привлек профессионалов по разработке, рассказал им свою идею и доверил им принятие решений. Идеи были хорошие, обоснованные. У одного ген дира был hardware-продукт, и он заказывал к нему мобильное приложение, чтобы завоевать сердца молодого поколения. У другого - успешный бизнес в реальном секторе, и он организовал IT-стартап, ISV. Причина их разочарования в том, что они увидели совершенно неадекватный бизнес-результат от вложения этих денег.
Мой вопрос даже не в том, почему никто из лиц, принимающих решение по разработке (сокращаю, ЛПР), не задумывается о бизнес-результате перед разработкой. Это мне понятно, их это якобы не касается. Мой вопрос в том, почему лицо действительно принимающее решение (сокращаю, ЛДПР), ген дир в данных конкретных случаях, не проговаривает свои ожидания от ЛПРов перед тем, как выдать им бюджет? Ведь это простой вопрос: "Что конкретно мы будем делать после того, как подрядчик отгрузит нам приложения?". Ему обычно поют песни про то, что мы сможем делать, а надо спрашивать другое - что конкретно мы будем делать.
Это нормально, что ген дир почти ничего не понимает в ТЗ. Поэтому он даже не пытается контролировать расходование денег в процессе разработки. У него на это есть наемные профессионалы. Но план действий по внедрению и использованию этих приложений он же может понять. И концентрат боли в том, что никто из ЛПРов как правило не видит картинку целиком. И если бы ЛДПР попытался эту картинку собрать, то понял бы, что кроме него её никто не видит. Но они принимают решения.
На пресейле это даже слышно. Когда подрядчик пытается как-то снижать риски заказчика по неадекватному возврату инвестиций, он встречает недоумение, раздражение и отторжение ЛПРов "Вы нам приложение сделайте, а мы потом сами решим, что с ним делать". В результате, когда дело доходит до внедрения, сова на глобус не натягивается и бизнесовые результаты оставляют желать сильно лучшего. При этом подрядчик разводит руками - он сделал всё по ТЗ. Проектный офис тоже - они всё тщательно проконтролировали. Функциональные руководители говорят что-то вроде "к пуговицам претензии есть?". Вобщем, все кругом не виноваты.
А если работали по аджайлу, хотя по аджайлу работать невозможно, можно работать по одному из аджайл фреймворков, то там, не смотря на то, что каждый спринт что-то было готово к релизу, скоуп был распределен так, что применить и получить какой то бизнес результат было возможно только на последних спринтах. И значит смысла в итеративности было мало. Формально вроде бы все по аджайлу, но никто не собирался использовать преимущества такого подхода для бизнеса.
Я говорю не о абстрактной бизнес-ценности в разработке. А то я видел, как подрядчик задает заказчику вопросы про ROI, хотя явно не в состоянии его понять и посчитать. Не всегда надо делать расчет ROI, но всегда перед началом, или хотя бы в процессе разработки нужно спрашивать о конкретных действиях по внедрению приложения и получению конкретных бизнесовых результатов.
Один подход, чтобы не сжечь впустую: тщательный подбор подрядчика, PMO и тщательно проработанное ТЗ. Другой подход - работать "по аджайлу": кросс-функциональная команда in-house, которая выдает на демо кусочек скоупа работ каждый спринт. Однако, оба подхода приводят к бестолковому сливу бюджета на разработку. На моем опыте сливали ~25, 90 и даже 250 млн руб.
Конечно, это я слегка приукрасил. Их не потеряли. За них получили удобные функциональные приложения. Однако, проблема в том, что условный ген дир, который заказывал музыку, потерял надежду и перекрыл финансирование, перевел их на техподдержку.
Почему? Этот ген дир ожидал какую-то бизнес-динамику от этих приложений. Поэтому привлек профессионалов по разработке, рассказал им свою идею и доверил им принятие решений. Идеи были хорошие, обоснованные. У одного ген дира был hardware-продукт, и он заказывал к нему мобильное приложение, чтобы завоевать сердца молодого поколения. У другого - успешный бизнес в реальном секторе, и он организовал IT-стартап, ISV. Причина их разочарования в том, что они увидели совершенно неадекватный бизнес-результат от вложения этих денег.
Мой вопрос даже не в том, почему никто из лиц, принимающих решение по разработке (сокращаю, ЛПР), не задумывается о бизнес-результате перед разработкой. Это мне понятно, их это якобы не касается. Мой вопрос в том, почему лицо действительно принимающее решение (сокращаю, ЛДПР), ген дир в данных конкретных случаях, не проговаривает свои ожидания от ЛПРов перед тем, как выдать им бюджет? Ведь это простой вопрос: "Что конкретно мы будем делать после того, как подрядчик отгрузит нам приложения?". Ему обычно поют песни про то, что мы сможем делать, а надо спрашивать другое - что конкретно мы будем делать.
Это нормально, что ген дир почти ничего не понимает в ТЗ. Поэтому он даже не пытается контролировать расходование денег в процессе разработки. У него на это есть наемные профессионалы. Но план действий по внедрению и использованию этих приложений он же может понять. И концентрат боли в том, что никто из ЛПРов как правило не видит картинку целиком. И если бы ЛДПР попытался эту картинку собрать, то понял бы, что кроме него её никто не видит. Но они принимают решения.
На пресейле это даже слышно. Когда подрядчик пытается как-то снижать риски заказчика по неадекватному возврату инвестиций, он встречает недоумение, раздражение и отторжение ЛПРов "Вы нам приложение сделайте, а мы потом сами решим, что с ним делать". В результате, когда дело доходит до внедрения, сова на глобус не натягивается и бизнесовые результаты оставляют желать сильно лучшего. При этом подрядчик разводит руками - он сделал всё по ТЗ. Проектный офис тоже - они всё тщательно проконтролировали. Функциональные руководители говорят что-то вроде "к пуговицам претензии есть?". Вобщем, все кругом не виноваты.
А если работали по аджайлу, хотя по аджайлу работать невозможно, можно работать по одному из аджайл фреймворков, то там, не смотря на то, что каждый спринт что-то было готово к релизу, скоуп был распределен так, что применить и получить какой то бизнес результат было возможно только на последних спринтах. И значит смысла в итеративности было мало. Формально вроде бы все по аджайлу, но никто не собирался использовать преимущества такого подхода для бизнеса.
Я говорю не о абстрактной бизнес-ценности в разработке. А то я видел, как подрядчик задает заказчику вопросы про ROI, хотя явно не в состоянии его понять и посчитать. Не всегда надо делать расчет ROI, но всегда перед началом, или хотя бы в процессе разработки нужно спрашивать о конкретных действиях по внедрению приложения и получению конкретных бизнесовых результатов.
ЛДПР не задает эти вопросы потому, что не чувствует там никакого подвоха. Он доверяет профессионалам. А они не утруждают себя провести ключевую цепочку причинно-следственной связи: такой-то фукнционал, будучи примененным таким-то образом в бизнесе, даст такой-то бизнес-эффект. Например, внедрив цифровую систему учета номенклатуры в производство получим снижение операционных расходов на сборку единицы изделия, и залив в маркетинг X млн руб, получим рост темпов производства с Y до Z в месяц. Риск в том, что даже если это уже факт, который проверен другими игроками рынка, что сомнительно - каждый бизнес по своему уникален. Так вот, даже если это факт, почему его так трудно проговорить хотя бы ЛПРам, не говоря уже о подрядчиках? Чтоб они понимали свою меру ответственности.
Это важно понять: любая разработка отбивается только на масштабе, росте либо прибыли, либо выручки. И когда мне начинают затыкать рот тем, что разработка нужна для повышения эффективности бизнес-процессов, я всегда спрашиваю - и что вы будете делать с этой повышенной эффективностью? Её на хлеб не намажешь и в карман не положишь. И вы же уже знаете ответ: "С этим мы потом разберемся". Ну а вы когда будете разбираться, то какова вероятность, что вы угадали где именно низкая эффективность мешает осуществить итоговый план? И вроде подрядчик не виноват в том, что ему недвусмысленно указали на его место в духе "не ваше дело", но он тоже получит проблему - труднозакрываемую дебеторку.
Итак, как решать эту проблему?
Если вы - ЛДПР, не давайте бюджет, пока ЛПР не расскажет, как эти деньги на разработку отобьются в конкретных бизнесовых результатах. Помните, вы в данном случае - инвестор, и поэтому требуйте объяснить вам механизм возврата этих инвестиций.
Если вы - РП или продакт, который принимает решения по требованиям в разработке и занимается приемкой, не поленитесь, задайте эти вопросы ЛДПРу и помогите ему снизить риски. Если там действительно большой риск, то лучше перестроить проект так, чтоб получить какие-то ранние версии ПО, с помощью которых можно сходить в рынок/операционку и проверить соответствующие гипотезы.
Если вы - подрядчик, у которого нет связи с ЛДПРом, а ЛПРы вам затыкают рот и пытаются вернуть вас в стойло, попробуйте разбить проект на части так, чтобы каждая часть отгружалась за ~месяц, и требуйте оплаты за каждую часть (желательно частичная предоплата), чтобы неадекватные ЛПРы не похоронили вас вместе с этим проектом.
Всем желаю крутых проектов, в результате которых бизнес успешно отбивает вложенные средства!
Это важно понять: любая разработка отбивается только на масштабе, росте либо прибыли, либо выручки. И когда мне начинают затыкать рот тем, что разработка нужна для повышения эффективности бизнес-процессов, я всегда спрашиваю - и что вы будете делать с этой повышенной эффективностью? Её на хлеб не намажешь и в карман не положишь. И вы же уже знаете ответ: "С этим мы потом разберемся". Ну а вы когда будете разбираться, то какова вероятность, что вы угадали где именно низкая эффективность мешает осуществить итоговый план? И вроде подрядчик не виноват в том, что ему недвусмысленно указали на его место в духе "не ваше дело", но он тоже получит проблему - труднозакрываемую дебеторку.
Итак, как решать эту проблему?
Если вы - ЛДПР, не давайте бюджет, пока ЛПР не расскажет, как эти деньги на разработку отобьются в конкретных бизнесовых результатах. Помните, вы в данном случае - инвестор, и поэтому требуйте объяснить вам механизм возврата этих инвестиций.
Если вы - РП или продакт, который принимает решения по требованиям в разработке и занимается приемкой, не поленитесь, задайте эти вопросы ЛДПРу и помогите ему снизить риски. Если там действительно большой риск, то лучше перестроить проект так, чтоб получить какие-то ранние версии ПО, с помощью которых можно сходить в рынок/операционку и проверить соответствующие гипотезы.
Если вы - подрядчик, у которого нет связи с ЛДПРом, а ЛПРы вам затыкают рот и пытаются вернуть вас в стойло, попробуйте разбить проект на части так, чтобы каждая часть отгружалась за ~месяц, и требуйте оплаты за каждую часть (желательно частичная предоплата), чтобы неадекватные ЛПРы не похоронили вас вместе с этим проектом.
Всем желаю крутых проектов, в результате которых бизнес успешно отбивает вложенные средства!
В конце 90-х формат user story придумал соавтор Agile-манифеста Кент Бек, когда заметил что требования в формате подробного многостраничного документа не способствуют снижению рисков бизнеса. Требования пытаются быть точными за счёт формальности, но это стремление лишь увеличивает иллюзию взаимопонимания между бизнесом и разработчиками. Подписывая документ, они понимают его по-разному, но думают что пришли к соглашению. Поэтому неудобства, лишние функции и недостаток нужных функций вскрываются слишком поздно - во время релиза, когда начинается поиск виноватых в его провале.
Чтобы эти проблемы вскрывались пораньше, представители бизнеса и разработчики должны иметь возможность обсудить не столько будущий функционал, сколько проблемы и задачи которые с помощью него будут решаться. Поэтому Кент Бек придумал user story. По сути, это даже не требования. Это дополнительный верхнеуровневый слой над требованиями, который помогает проверить их целесообразность и согласованность.
Основные элементы user story:
1. роль, чтобы пользователь/бизнес понимал, про кого эта фича
2. проблема/задача, которую роль сейчас решает не лучшим образом
3. альтернативное решение проблемы/задачи, которое разработчики предлагают роли вместе с соответствующим функционалом
Чтобы убедиться, что ваши user story правильно написаны, убедитесь, что в них видно, как и для чего роль будет пользоваться соответствующими функциями. Если вы обнаружили себя в процессе выдумывания 2-го, самого важного элемента истории, то не надо писать эту user story. 2-й элемент должен быть фактом, который вам сообщил заказчик, а не попыткой оправдать чье-то желание запилить то, что написано в 3-м элементе. Также, очевидно, нет никакого смысла использовать user story над NFR, типа повышения отказоустойчивости, портирования с web на ios/android и т.д.
Например, секретарь тратит целый день в месяц, чтобы вручную составить и разослать 20-30 счетов клиентам. Разработчики пилят автоматизацию, с помощью которой секретарь будет делать рассылку автоматически. Основные фичи: сбор статистики использования системы, расчет цены из тарифов, генерация PDF-счетов, интерфейс проверки данных перед рассылкой и сама автоматическая рассылка.
Для секретаря очевидно, что эти фичи нужны, чтобы сэкомить его время. Поэтому нет никакого смысла писать user story вида "Мне как секретарю нужна функция расчета цены из таблицы тарифов, чтоб не делать этого вручную и сэкономить время". Потому что это капитанская история и она ничего не рассказывает о том, как эта функция будет использоваться.
Вместо этого, спросите себя, что будет делать секретарь после релиза? Открывать уже подготовленные к рассылке данные по всем клиентам, пробегаться по ним глазами и аппрувить рассылку нажатием кнопки. Это и нужно написать: "Мне как секретарю нужно проверить правильность расчета начислений перед рассылкой, чтобы избежать ошибочной оплаты клиентами".
Мы, как разработчики, в данном случае пилим 5 полезных фичей, которые потенциально можно внедрить отдельно, и поэтому руки чешутся написать 5 user story. Но поскольку мы собираемся внедрять все 5 сразу, то пользовательская история на все 5 будет только одна - потому что секретарь будет пользоваться только интерфейсом проверки. Из этого сделаем ещё один важный вывод: кол-во user story зависит не от количества фичей, которые мы собираемся релизить, а от процесса внедрения этих фичей в конкретные операции или сервисные элементы бизнеса.
Реальная цель формата user story - облегчение диалога между бизнесом и разработкой. Поэтому самое интересное происходит, когда мы расскажем эту историю реальному секретарю. Он сразу скажет "А что я буду делать, если в расчетах нашлись ошибки?" и мы сразу увидим, что забыли учесть какой-то механизм коррекции расчетов.
Итак, не пишите user story только потому, что вам нравится этот формат. Пишите функциональные требования в привычном традиционном формате, а user story используйте только тогда, когда есть возможность изучить и обсудить с заказчиком будущий процесс внедрения.
Чтобы эти проблемы вскрывались пораньше, представители бизнеса и разработчики должны иметь возможность обсудить не столько будущий функционал, сколько проблемы и задачи которые с помощью него будут решаться. Поэтому Кент Бек придумал user story. По сути, это даже не требования. Это дополнительный верхнеуровневый слой над требованиями, который помогает проверить их целесообразность и согласованность.
Основные элементы user story:
1. роль, чтобы пользователь/бизнес понимал, про кого эта фича
2. проблема/задача, которую роль сейчас решает не лучшим образом
3. альтернативное решение проблемы/задачи, которое разработчики предлагают роли вместе с соответствующим функционалом
Чтобы убедиться, что ваши user story правильно написаны, убедитесь, что в них видно, как и для чего роль будет пользоваться соответствующими функциями. Если вы обнаружили себя в процессе выдумывания 2-го, самого важного элемента истории, то не надо писать эту user story. 2-й элемент должен быть фактом, который вам сообщил заказчик, а не попыткой оправдать чье-то желание запилить то, что написано в 3-м элементе. Также, очевидно, нет никакого смысла использовать user story над NFR, типа повышения отказоустойчивости, портирования с web на ios/android и т.д.
Например, секретарь тратит целый день в месяц, чтобы вручную составить и разослать 20-30 счетов клиентам. Разработчики пилят автоматизацию, с помощью которой секретарь будет делать рассылку автоматически. Основные фичи: сбор статистики использования системы, расчет цены из тарифов, генерация PDF-счетов, интерфейс проверки данных перед рассылкой и сама автоматическая рассылка.
Для секретаря очевидно, что эти фичи нужны, чтобы сэкомить его время. Поэтому нет никакого смысла писать user story вида "Мне как секретарю нужна функция расчета цены из таблицы тарифов, чтоб не делать этого вручную и сэкономить время". Потому что это капитанская история и она ничего не рассказывает о том, как эта функция будет использоваться.
Вместо этого, спросите себя, что будет делать секретарь после релиза? Открывать уже подготовленные к рассылке данные по всем клиентам, пробегаться по ним глазами и аппрувить рассылку нажатием кнопки. Это и нужно написать: "Мне как секретарю нужно проверить правильность расчета начислений перед рассылкой, чтобы избежать ошибочной оплаты клиентами".
Мы, как разработчики, в данном случае пилим 5 полезных фичей, которые потенциально можно внедрить отдельно, и поэтому руки чешутся написать 5 user story. Но поскольку мы собираемся внедрять все 5 сразу, то пользовательская история на все 5 будет только одна - потому что секретарь будет пользоваться только интерфейсом проверки. Из этого сделаем ещё один важный вывод: кол-во user story зависит не от количества фичей, которые мы собираемся релизить, а от процесса внедрения этих фичей в конкретные операции или сервисные элементы бизнеса.
Реальная цель формата user story - облегчение диалога между бизнесом и разработкой. Поэтому самое интересное происходит, когда мы расскажем эту историю реальному секретарю. Он сразу скажет "А что я буду делать, если в расчетах нашлись ошибки?" и мы сразу увидим, что забыли учесть какой-то механизм коррекции расчетов.
Итак, не пишите user story только потому, что вам нравится этот формат. Пишите функциональные требования в привычном традиционном формате, а user story используйте только тогда, когда есть возможность изучить и обсудить с заказчиком будущий процесс внедрения.