О-о-о, вы бы удивились какой бардак творится в вопросах приоритезации бэклога!
Я довольно регулярно собеседую продактов — в основном мидл+ и синьор уровней. И, чтобы понять как они мыслят, всегда расспрашиваю — как они генерили гипотезы, как их приоритезировали и т.д.
Так вот даже в крупных компаниях часто берут в работу задачи, потому что "СЕО настоял", "команда очень хотела", "пользователи пожаловались", "конкуренты такое сделали", "оунер очень верил в эту идею" и т.д. В лучшем случае используют RICE или ICE методологии. Но реальную приоритезацию на основе прибыли, с учетом маржинальности, с расчетом срока окупаемости — такое делают единицы.
А самая дичь творится в госкорпорациях, там люди вообще не понимают слова "окупаемость". Мыслят категориями "освоить бюджет" и "руководитель так сказал". Я такого наслушался, что до сих пор кошмары снятся))
"Передернули", "порете хрень", "спекуляции" — фу таким быть.
Но я вижу, что другие люди ваш комментарий читают, поэтому отвечу для них, а не для вас. Тем более это позволит глубже раскрыть некоторые тезисы статьи.
Типичная история именно для автоматизации:
Увидели проблемы в операционке→ Автоматизировали операционку
Вместо этого, я предлагаю действовать так:
Увидели проблему в операционке→ Оцениваем её в масштабе всего бизнеса→ Автоматизируем только если это повлияет на наши ключевые метрики
Конечно, так оценивать нужно любую задачу. Но, на моей практике, ошибки допускаются чаще именно при автоматизации. Думаю, это связано с иллюзией экономии, которую она дает.
Аналитикам, с которыми я работаю, обычно нужно 5-15 минут, чтобы подправить SQL-запрос. За это время можно разве что оформить задачу на разработчика, но точно не сделать её, не проверить её и не вылить её.
Плюс разработчик же не делает задачу в вакууме — он делает задачу вместо какой-то другой, полезной задачи. Я всегда очень осторожно отношусь к тому, чтобы грузить разработчика чем попало.
P. S. Солидарен с комментарием qw1 выше. Видно, что человек уже сталкивался с подобными ситуациями на практике.
Предполагаю, что ваш опыт из другой области — возможно, вы работаете в аутсорсе? Я же говорю о работе над собственным продуктом. В любом случае, постараюсь ответить по пунктам.
Почему проджект? Разве проджект проектирует автоматизацию, общается с заказчиками, продумывает кейсы, пишет техзадание? У него ж совсем другая роль. Конечно речь о продакте или хотя бы бизнес-аналитике.
Смотря что вы имеете в виду под оценкой проекта. Если эстимейт задачи разработчиками — то, конечно, все оценивают размер задач, это обычная практика. Если же речь о финансовойоценке окупаемостикаждойфичи или гипотезы — то это встречается довольно редко, только в компаниях с сильной продуктовой экспертизой.
Не очень понял вот это сочетание: "местячковый, аморальный и с опытом до 2 лет") Откуда такая статистика? Я собеседовал достаточно продактов из крупных городов и компаний, и вот что могу сказать: продакты с опытом до 5 лет очень редко умеют делать автоматизацию грамотно (не наворотить космолет, учесть все кейсы, качественно опросить заказчика и т.д.). В Белоснежку продакт превращается где-то на границе 5-7 лет опыта. Но, понятно, всегда есть исключения.
Конечно, никто не держит аналитика ради одного отчета. Но типичная ситуация, когда в обязанности аналитика, помимо всего прочего, входит и несколько регулярных выгрузок из БД.
С последним вашим тезисом "Вредит не автоматизация. Вредит отсутствие проработки и понимания для чего это все делается и к чему приведет" - согласен. Но как раз в этом и задача статьи — дать понимание "как повлияет автоматизация" тем, кто ещё не совсем это понимает :)
Ну это, кстати, хороший кейс, когда кто-то может самостоятельно свою работу автоматизировать.
Я когда-то, в позапрошлой жизни, был верстальщиком в еженедельной газете. А верстальщик, работавший до меня, тратил по несколько часов на финальное форматирование текста (всякие отступы, кавычки, выделения, стили). Довольно муторная скучная работа, которая требует большой внимательности. После такого глаза гарантированные красные. И так каждую неделю. И нет права на ошибку, т.к. потом газета отправлялась в типографию и печаталась тысячами экземпляров. Помнится, я написал какой-то несложный скрипт, который делал всё это форматирование автоматически, за несколько минут. Об этой автоматизации я не пожалел))
Ну да, в самих задачах ничего плохого нет.
Хотя, мне кажется, всё же интереснее делать какую-то новую полезную фичу для пользователей, чем обновлять библиотеку.
Но тут больше речь о том, чтобы люди, которые планируют разработку (например, проектные менеджеры) — трезво оценивали сроки, объем работ, риски и т.д.
Да, тоже с этим сталкивался.
Причем это касается не только людей с ограниченными возможностями — у меня на телефоне установлен шрифт на один размер больше стандартного (не потому что я плохо вижу, а просто мне так удобнее). И это иногда ломает верстку.
Спасибо за интересный комментарий!
Когда работал в геймдеве — тоже сталкивался с большими числами.
Например, однажды, мы поставили небольшую вероятность выпадения премиум-предметов во время новогоднего ивента. Но это мы думали, что она «небольшая».
А количество игроков и их усердие привели к тому, что выпало слишком много таких предметов и продажи просели на целый месяц. Но, правда, игроки были счастливы)
Да, помню у меня были сложности с приложением, так я так и не достучался до поддержки Google. Предлагают читать справку и задавать вопросы сообществу, насколько помню.
Да, можно и в джире, конечно.
Статья больше о том, как сделать общение с заказчиками асинхронным, не требующим избыточного участия. А выбор инструмента вторичен.
Но мне есть, что сказать в защиту таблиц.
Во-первых, таблицы универсальны – все знают, как ими пользоваться и у всех есть gmail-аккаунт. Вы просто бросаете ссылку человеку, и он уже пользуется вашей таблицей.
Другое дело та же jira – она совсем не простая для человека вне IT. Попробуйте обучить сэйлза правильно оформлять задачу в джире – это будет не просто. И не потому, что сэйлз глупый, просто джира заточена под другие задачи, а сэйлз работает вообще в другом контексте. Ему придется специально заводить аккаунт только ради того, чтобы оставить вам запрос.
Мы даже пробовали нечто подобное – настроили Service Desk, который сам формировал задачи в джиру. Если сотрудник видел баг, то ему нужно было оформить его в Service Desk. Так вот, что удалось понять из этого эксперимента – большинство сотрудников не хотят таких заморочек. Когда человеку нужно прикладывать усилия, чтобы просто сообщить об ошибке в продукте – ему проще пройти мимо. Работают только простые инструменты – написать в чат или максимум в таблицу.
Во-вторых, таблицы реально удобные. Быстро грузятся, легко редактируются, можно совместно работать над документом. А в том же confluence (несмотря на мою любовь к нему) – совместная работа это тот еще головняк.
В третьих, таблицы достаточно надежные. Тут вот пишут, что могут случайно затираться данные – но я вообще с таким не сталкивался. Да и сохраняется все автоматически в облаке, с историей версий. А вот потерять карточку на общей доске Trello – проще простого.
В общем, мое мнение: специализированные инструменты хороши для персональной работы или работы в рамках одного отдела. А таблицы более универсальны и подходят для совместной работы разношерстных отделов в рамках большой компании.
Да, про обучение сотрудников плюсую. Для людей вне IT, jira — это ад.
Про Definition of Done — я не ожидаю, что человек из финотдела, например, напишет запрос сразу в таком формате. На мой взгляд, это все-таки задача продакта — выявить реальную потребность, оценить нужно ли это делать, найти оптимальный вариант решения и оформить задачу как полагается.
Бывает, просят сделать какую-то фичу, а когда докапываешься до настоящей причины — оказывается это можно решить совсем иначе, значительно проще, а иногда и вовсе без разработки.
А гугл-формы — да, нормальный вариант, мы его тоже используем.
Но тут уже зависит от ситуации:
Если говорим о запросах от руководителей отделов, то они итак ничего не ломают, но могут дописать что-то важное в задачу по моей просьбе. А гугл-форма этого не позволяет.
Зато запросы на аналитику у нас сделаны именно так — заказчик оставляет запрос в гугл-форме, а потом может видеть свой запрос и ответ аналитика в таблице, которая доступна только для чтения.
Безусловно, для профессиональной работы именно с задачами – нужны нормальные инструменты. Мы для этого используем jira и confluence.
Но это инструменты для IT и Product отделов. А когда мы взаимодействуем с операционными отделами – то им намного проще оставить запрос в табличке, чем разбираться с оформлением таски в jira.
Что касается сроков реализации – то обычно внутренним заказчикам достаточно общих сроков типа «выливка будет в конце марта» или «задача вошла в следующий спринт».
А что делать с затиранием табличек – выше ответил. У нас такой проблемы нет от слова совсем. Хотя сейчас в компании под 200 сотрудников и 70% документации ведем именно в таблицах.
Много комментариев о том, что могут затереть данные.
Не знаю почему, но я вот вообще с этим никогда не сталкивался (хотя большинство доков ведем в таблицах).
Может быть дело в том, что почти всегда к таблице имеют доступ от 3 до 10 человек, кому это реально нужно.
Ну Хабр мне ближе по духу, но я пока еще в поиске своего формата.
Иногда сложно понять как это работает: в топе продуктового хаба висит статья о том, как парня кинули работодатели. Причем тут «управление продуктом»? Загадка.
Так что пока еще разбираюсь-осваиваюсь.
Спасибо, это реально мотивирует работать над новыми статьями — когда вижу, что кому-то это полезно :)
О-о-о, вы бы удивились какой бардак творится в вопросах приоритезации бэклога!
Я довольно регулярно собеседую продактов — в основном мидл+ и синьор уровней. И, чтобы понять как они мыслят, всегда расспрашиваю — как они генерили гипотезы, как их приоритезировали и т.д.
Так вот даже в крупных компаниях часто берут в работу задачи, потому что "СЕО настоял", "команда очень хотела", "пользователи пожаловались", "конкуренты такое сделали", "оунер очень верил в эту идею" и т.д. В лучшем случае используют RICE или ICE методологии. Но реальную приоритезацию на основе прибыли, с учетом маржинальности, с расчетом срока окупаемости — такое делают единицы.
А самая дичь творится в госкорпорациях, там люди вообще не понимают слова "окупаемость". Мыслят категориями "освоить бюджет" и "руководитель так сказал". Я такого наслушался, что до сих пор кошмары снятся))
Ну это, кстати, хороший пример и подтверждение тезиса, что нельзя "раз и навсегда" сделать автоматизацию и просто забыть про неё :)
Спасибо большое за этот комментарий!
Признаться, мне нелегко дается написание статей. Конкретно для этой я около года делал заметки и собирал кейсы, а потом пару месяцев шлифовал текст.
Но когда вижу такие комментарии, то кажется, что всё было не зря :)
Спасибо, ценный комментарий, хорошо дополняет статью.
Вообще, обычно не отвечаю на хамские комментарии.
"Передернули", "порете хрень", "спекуляции" — фу таким быть.
Но я вижу, что другие люди ваш комментарий читают, поэтому отвечу для них, а не для вас. Тем более это позволит глубже раскрыть некоторые тезисы статьи.
Типичная история именно для автоматизации:
Увидели проблемы в операционке → Автоматизировали операционку
Вместо этого, я предлагаю действовать так:
Увидели проблему в операционке → Оцениваем её в масштабе всего бизнеса → Автоматизируем только если это повлияет на наши ключевые метрики
Конечно, так оценивать нужно любую задачу. Но, на моей практике, ошибки допускаются чаще именно при автоматизации. Думаю, это связано с иллюзией экономии, которую она дает.
Аналитикам, с которыми я работаю, обычно нужно 5-15 минут, чтобы подправить SQL-запрос. За это время можно разве что оформить задачу на разработчика, но точно не сделать её, не проверить её и не вылить её.
Плюс разработчик же не делает задачу в вакууме — он делает задачу вместо какой-то другой, полезной задачи. Я всегда очень осторожно отношусь к тому, чтобы грузить разработчика чем попало.
P. S. Солидарен с комментарием qw1 выше. Видно, что человек уже сталкивался с подобными ситуациями на практике.
Ну мне тогда было двадцать с чем-то лет, я такими критериями не мыслил. Все было проще — работать неудобно, сделаю удобнее :)
Из бонусов я тогда заработал только респекты от коллег.
Ну и как верно написал Crystal_HMR, в редакции до этого никто и не предполагал, что этот процесс вообще можно автоматизировать.
Предполагаю, что ваш опыт из другой области — возможно, вы работаете в аутсорсе? Я же говорю о работе над собственным продуктом. В любом случае, постараюсь ответить по пунктам.
Почему проджект? Разве проджект проектирует автоматизацию, общается с заказчиками, продумывает кейсы, пишет техзадание? У него ж совсем другая роль. Конечно речь о продакте или хотя бы бизнес-аналитике.
Смотря что вы имеете в виду под оценкой проекта. Если эстимейт задачи разработчиками — то, конечно, все оценивают размер задач, это обычная практика. Если же речь о финансовой оценке окупаемости каждой фичи или гипотезы — то это встречается довольно редко, только в компаниях с сильной продуктовой экспертизой.
Не очень понял вот это сочетание: "местячковый, аморальный и с опытом до 2 лет") Откуда такая статистика? Я собеседовал достаточно продактов из крупных городов и компаний, и вот что могу сказать: продакты с опытом до 5 лет очень редко умеют делать автоматизацию грамотно (не наворотить космолет, учесть все кейсы, качественно опросить заказчика и т.д.). В Белоснежку продакт превращается где-то на границе 5-7 лет опыта. Но, понятно, всегда есть исключения.
Конечно, никто не держит аналитика ради одного отчета. Но типичная ситуация, когда в обязанности аналитика, помимо всего прочего, входит и несколько регулярных выгрузок из БД.
С последним вашим тезисом "Вредит не автоматизация. Вредит отсутствие проработки и понимания для чего это все делается и к чему приведет" - согласен. Но как раз в этом и задача статьи — дать понимание "как повлияет автоматизация" тем, кто ещё не совсем это понимает :)
Ну это, кстати, хороший кейс, когда кто-то может самостоятельно свою работу автоматизировать.
Я когда-то, в позапрошлой жизни, был верстальщиком в еженедельной газете. А верстальщик, работавший до меня, тратил по несколько часов на финальное форматирование текста (всякие отступы, кавычки, выделения, стили). Довольно муторная скучная работа, которая требует большой внимательности. После такого глаза гарантированные красные. И так каждую неделю. И нет права на ошибку, т.к. потом газета отправлялась в типографию и печаталась тысячами экземпляров.
Помнится, я написал какой-то несложный скрипт, который делал всё это форматирование автоматически, за несколько минут. Об этой автоматизации я не пожалел))
Хотя, мне кажется, всё же интереснее делать какую-то новую полезную фичу для пользователей, чем обновлять библиотеку.
Но тут больше речь о том, чтобы люди, которые планируют разработку (например, проектные менеджеры) — трезво оценивали сроки, объем работ, риски и т.д.
Причем это касается не только людей с ограниченными возможностями — у меня на телефоне установлен шрифт на один размер больше стандартного (не потому что я плохо вижу, а просто мне так удобнее). И это иногда ломает верстку.
Когда работал в геймдеве — тоже сталкивался с большими числами.
Например, однажды, мы поставили небольшую вероятность выпадения премиум-предметов во время новогоднего ивента. Но это мы думали, что она «небольшая».
А количество игроков и их усердие привели к тому, что выпало слишком много таких предметов и продажи просели на целый месяц. Но, правда, игроки были счастливы)
Порядок такой:
И вот на этом этапе бывает задержка.
Тут три варианта развития событий:
Статья больше о том, как сделать общение с заказчиками асинхронным, не требующим избыточного участия. А выбор инструмента вторичен.
Но мне есть, что сказать в защиту таблиц.
Во-первых, таблицы универсальны – все знают, как ими пользоваться и у всех есть gmail-аккаунт. Вы просто бросаете ссылку человеку, и он уже пользуется вашей таблицей.
Другое дело та же jira – она совсем не простая для человека вне IT. Попробуйте обучить сэйлза правильно оформлять задачу в джире – это будет не просто. И не потому, что сэйлз глупый, просто джира заточена под другие задачи, а сэйлз работает вообще в другом контексте. Ему придется специально заводить аккаунт только ради того, чтобы оставить вам запрос.
Мы даже пробовали нечто подобное – настроили Service Desk, который сам формировал задачи в джиру. Если сотрудник видел баг, то ему нужно было оформить его в Service Desk. Так вот, что удалось понять из этого эксперимента – большинство сотрудников не хотят таких заморочек. Когда человеку нужно прикладывать усилия, чтобы просто сообщить об ошибке в продукте – ему проще пройти мимо. Работают только простые инструменты – написать в чат или максимум в таблицу.
Во-вторых, таблицы реально удобные. Быстро грузятся, легко редактируются, можно совместно работать над документом. А в том же confluence (несмотря на мою любовь к нему) – совместная работа это тот еще головняк.
В третьих, таблицы достаточно надежные. Тут вот пишут, что могут случайно затираться данные – но я вообще с таким не сталкивался. Да и сохраняется все автоматически в облаке, с историей версий. А вот потерять карточку на общей доске Trello – проще простого.
В общем, мое мнение: специализированные инструменты хороши для персональной работы или работы в рамках одного отдела. А таблицы более универсальны и подходят для совместной работы разношерстных отделов в рамках большой компании.
Про Definition of Done — я не ожидаю, что человек из финотдела, например, напишет запрос сразу в таком формате. На мой взгляд, это все-таки задача продакта — выявить реальную потребность, оценить нужно ли это делать, найти оптимальный вариант решения и оформить задачу как полагается.
Бывает, просят сделать какую-то фичу, а когда докапываешься до настоящей причины — оказывается это можно решить совсем иначе, значительно проще, а иногда и вовсе без разработки.
А гугл-формы — да, нормальный вариант, мы его тоже используем.
Но тут уже зависит от ситуации:
Но это инструменты для IT и Product отделов. А когда мы взаимодействуем с операционными отделами – то им намного проще оставить запрос в табличке, чем разбираться с оформлением таски в jira.
Что касается сроков реализации – то обычно внутренним заказчикам достаточно общих сроков типа «выливка будет в конце марта» или «задача вошла в следующий спринт».
А что делать с затиранием табличек – выше ответил. У нас такой проблемы нет от слова совсем. Хотя сейчас в компании под 200 сотрудников и 70% документации ведем именно в таблицах.
Не знаю почему, но я вот вообще с этим никогда не сталкивался (хотя большинство доков ведем в таблицах).
Может быть дело в том, что почти всегда к таблице имеют доступ от 3 до 10 человек, кому это реально нужно.
Иногда сложно понять как это работает: в топе продуктового хаба висит статья о том, как парня кинули работодатели. Причем тут «управление продуктом»? Загадка.
Так что пока еще разбираюсь-осваиваюсь.