Опять увидел холивар на тему: нужны ли аналитики или нет.
Человек, который отстаивал позицию «аналитики нужны», говорил вполне разумные вещи:
про разделение труда как основу эффективности,
про снижение рисков некомпетентности,
про тушение пожаров,
про то, что аналитик — универсальная страховка.
И вот тут мне стало интересно.
В комментариях начали всплывать знакомые истории из серии:
«Работал в проекте, где бизнес ходил напрямую к разработчикам. Разработчики ничего не уточняли, что-то делали. Потом выяснялось, что это никому не нужно, всё ломало, никто не понимал, что вообще произошло».
И в этот момент у меня возникает простой вопрос:
👉 а если туда поставить аналитика — что принципиально изменится?
Можно ли заткнуть эту дыру аналитиком?
Да, можно.
Перестанет ли от этого бизнес приходить с тупыми требованиями?
Скорее всего — нет.
Перестанут ли разработчики делать странные, плохо продуманные доработки?
Тоже вряд ли.
С высокой вероятностью аналитик просто подстроится под этот бардак и станет той самой «универсальной затычкой», которая:
• переписывает мысли бизнеса в задачи,
• сглаживает конфликты,
• объясняет последствия задним числом,
• и героически тушит пожары.
Но проблема-то не в отсутствии аналитика.
Проблема — в процессах.
В том, что:
• люди не вовлечены,
• бизнес не думает о стоимости изменений,
• разработчики делают «что сказали», не понимая зачем,
• никто не владеет системой целиком.
Разработчики сидят и «кодят», потому что надо кодить.
Бизнес вбрасывает требования, потому что «кажется, так надо».
Никто не думает про целостность, ценность, последствия и приоритеты.
И вот здесь, как ни странно, аналитик не ключевая роль.
Здесь нужен владелец процесса.
Человек, который:
• понимает, как работает система,
• знает, зачем вообще делаются изменения,
• умеет сказать бизнесу «нет» или «не сейчас»,
• вовлекает разработчиков в смысл, а не просто раздаёт задачи.
Назовите его как угодно:
Product Owner, Product Manager, Technical Product Manager — не так важно.
Важно, что это роль с ownership, а не с обслуживанием.
Аналитик в такой системе появляется уже вторым шагом —
когда есть продукт, есть владелец, есть контекст, и часть работы можно делегировать.
Проблема в том, что, по моим наблюдениям, многие аналитики не готовы брать на себя ownership.
Они хотят:
• делать задачи,
• писать требования,
• «чётко по ТЗ»,
• без ответственности за результат.
И в такой конфигурации не поможет ни один аналитик.
Хоть трёх посадите.
Поэтому моя позиция будет максимально провокационной:
👉 в идеальном мире аналитики не нужны.
Но как люди, которым продукт может делегировать часть работы —
они вполне себе полезны и уместны.
Ну что, давайте немного похоливарим 🙂
Человек, который отстаивал позицию «аналитики нужны», говорил вполне разумные вещи:
про разделение труда как основу эффективности,
про снижение рисков некомпетентности,
про тушение пожаров,
про то, что аналитик — универсальная страховка.
И вот тут мне стало интересно.
В комментариях начали всплывать знакомые истории из серии:
«Работал в проекте, где бизнес ходил напрямую к разработчикам. Разработчики ничего не уточняли, что-то делали. Потом выяснялось, что это никому не нужно, всё ломало, никто не понимал, что вообще произошло».
И в этот момент у меня возникает простой вопрос:
👉 а если туда поставить аналитика — что принципиально изменится?
Можно ли заткнуть эту дыру аналитиком?
Да, можно.
Перестанет ли от этого бизнес приходить с тупыми требованиями?
Скорее всего — нет.
Перестанут ли разработчики делать странные, плохо продуманные доработки?
Тоже вряд ли.
С высокой вероятностью аналитик просто подстроится под этот бардак и станет той самой «универсальной затычкой», которая:
• переписывает мысли бизнеса в задачи,
• сглаживает конфликты,
• объясняет последствия задним числом,
• и героически тушит пожары.
Но проблема-то не в отсутствии аналитика.
Проблема — в процессах.
В том, что:
• люди не вовлечены,
• бизнес не думает о стоимости изменений,
• разработчики делают «что сказали», не понимая зачем,
• никто не владеет системой целиком.
Разработчики сидят и «кодят», потому что надо кодить.
Бизнес вбрасывает требования, потому что «кажется, так надо».
Никто не думает про целостность, ценность, последствия и приоритеты.
И вот здесь, как ни странно, аналитик не ключевая роль.
Здесь нужен владелец процесса.
Человек, который:
• понимает, как работает система,
• знает, зачем вообще делаются изменения,
• умеет сказать бизнесу «нет» или «не сейчас»,
• вовлекает разработчиков в смысл, а не просто раздаёт задачи.
Назовите его как угодно:
Product Owner, Product Manager, Technical Product Manager — не так важно.
Важно, что это роль с ownership, а не с обслуживанием.
Аналитик в такой системе появляется уже вторым шагом —
когда есть продукт, есть владелец, есть контекст, и часть работы можно делегировать.
Проблема в том, что, по моим наблюдениям, многие аналитики не готовы брать на себя ownership.
Они хотят:
• делать задачи,
• писать требования,
• «чётко по ТЗ»,
• без ответственности за результат.
И в такой конфигурации не поможет ни один аналитик.
Хоть трёх посадите.
Поэтому моя позиция будет максимально провокационной:
👉 в идеальном мире аналитики не нужны.
Но как люди, которым продукт может делегировать часть работы —
они вполне себе полезны и уместны.
Ну что, давайте немного похоливарим 🙂