Про зомби-Scrum
#agile #что_почитать
Хочу поделиться парой статей о применении Agile фреймворков. Здесь скептические высказывания.
В техниках Agile подразумеваются определенным образом поставленные цели разработки, возможность совместного проектирования методом проб и ошибок. Когда чего-то из этого нет, то получается либо слепое следование ритуалам, либо попытки впихнуть реальность в методологию. Если вы строите мост и не можете себе позволить итеративных проб и ошибок, нужна ли такая гибкость? Действительно ли нужен фокус на гибкость, если продукт имеет четкий набор свойств и функций и они не меняются часто?
Зомби-Scrum: симптомы, причины и их лечение о слепом следовании ритуалам
Темная сторона Agile публикация давняя, но здесь понравился разбор картины с точки зрения кодовой базы, реформирования тестирования, мониторинга и пр.
#agile #что_почитать
Хочу поделиться парой статей о применении Agile фреймворков. Здесь скептические высказывания.
В техниках Agile подразумеваются определенным образом поставленные цели разработки, возможность совместного проектирования методом проб и ошибок. Когда чего-то из этого нет, то получается либо слепое следование ритуалам, либо попытки впихнуть реальность в методологию. Если вы строите мост и не можете себе позволить итеративных проб и ошибок, нужна ли такая гибкость? Действительно ли нужен фокус на гибкость, если продукт имеет четкий набор свойств и функций и они не меняются часто?
Зомби-Scrum: симптомы, причины и их лечение о слепом следовании ритуалам
Темная сторона Agile публикация давняя, но здесь понравился разбор картины с точки зрения кодовой базы, реформирования тестирования, мониторинга и пр.
🤔2👍1
Analyst Marathon #10. Теория и кейсы
#конференции #мысливслух
Суббота 10 утра для меня бывает временем неспешного завтрака, только на прошлой неделе пришлось изменить свой распорядок, чтобы подключиться к Analyst Marathon. В этой онлайн конференции мне нравится атмосфера — нет пафосных студий с белыми стенами и красивыми микрофонами, а есть эксперты, которые пришли пообщаться. Здесь доклады идут в записи, так что спикер выходит на связь, чтобы бодро и предметно ответить на вопросы из чата, где все участники набрасывают разной степени ехидности вопросы. Создается ощущение настоящего общения, потому что в динамике видишь и движуху чатике, и как докладчик на нее реагирует. Случались накладки, когда спикер подключался раньше, чем закончилась его запись или наоборот сильно опаздывал, но все это хорошо работало на теплую неформальную атмосферу.
Проводится конференция третий год, собирались уже 10й раз с темой «Технические навыки БА/СА”. Всего 6 докладов примерно за 6 часов.
Мне было интересно и полезно для общего образования послушать о брокерах сообщений, об архитектуре микросервисов, о проектировании БД, но подозреваю, что многие опытные системные аналитики могли заскучать.
Первый доклад был про единые подходы к управлению интеграциями систем и команд. Запомнилось наблюдение, что межкомандные регламенты важны если работает более трех команд, три команды еще могут договориться напрямую. Речь зашла о встречах-синхронизациях при разработке интеграций и мне стало интересно, кто на них ходит: разработчики, архитекторы, аналитики, QA? Докладчик Ильяс Мухамадуллин ответил - это человек, который в контексте задачи и может принимать решения в части интеграций: аналитик, архитектор, разработчик или тимлид 🤨
Неожиданно меня увлек доклад про выбор NoSQL в кейсе про справочник налогообложения для формирования чеков в ресторанах. Запомнилось, что в этом кейсе 180 секунд оказалось достаточно, чтобы оформить заказ в киоске, на кассе или в приложении. Это был предметный и искренний рассказ о выборе NoSQL для кеширования данных заказа. Татьяна Павлюченкова поделилась ссылкой на Миро, где выложена табличка с типами таких БД и критериями выбора для этого конкретного кейса.
Был доклад Ирины Матвеевой про ТРИЗ. Рассказ о постановке задачи по ТРИЗ и о сути подхода. Из переписки в чате сохранила себе ссылку на табличку из статьи Альтшуллера Г.С. Алгоритм изобретения (1973), где в зависимости от того, что нужно изменить для решения конкретного типа задачи указаны номера методов решения. Чтобы начать решать задачу нужно понять главную полезную функцию системы. Так что вопрос «какую проблему мы решаем?» выглядит вполне вопросом по ТРИЗ.
Некоторые доклады досматривала уже после окончания конференции и тогда же дочитывала чатик, где не обошлось без очередного обмена мнениями о разделении функций СА и БА, без него теперь редко обходится 🤷♀️
Вышло так, что в прошлую субботу перед ужином снова слушала доклады. И то, и другое было полезным 🌱
#конференции #мысливслух
Суббота 10 утра для меня бывает временем неспешного завтрака, только на прошлой неделе пришлось изменить свой распорядок, чтобы подключиться к Analyst Marathon. В этой онлайн конференции мне нравится атмосфера — нет пафосных студий с белыми стенами и красивыми микрофонами, а есть эксперты, которые пришли пообщаться. Здесь доклады идут в записи, так что спикер выходит на связь, чтобы бодро и предметно ответить на вопросы из чата, где все участники набрасывают разной степени ехидности вопросы. Создается ощущение настоящего общения, потому что в динамике видишь и движуху чатике, и как докладчик на нее реагирует. Случались накладки, когда спикер подключался раньше, чем закончилась его запись или наоборот сильно опаздывал, но все это хорошо работало на теплую неформальную атмосферу.
Проводится конференция третий год, собирались уже 10й раз с темой «Технические навыки БА/СА”. Всего 6 докладов примерно за 6 часов.
Мне было интересно и полезно для общего образования послушать о брокерах сообщений, об архитектуре микросервисов, о проектировании БД, но подозреваю, что многие опытные системные аналитики могли заскучать.
Первый доклад был про единые подходы к управлению интеграциями систем и команд. Запомнилось наблюдение, что межкомандные регламенты важны если работает более трех команд, три команды еще могут договориться напрямую. Речь зашла о встречах-синхронизациях при разработке интеграций и мне стало интересно, кто на них ходит: разработчики, архитекторы, аналитики, QA? Докладчик Ильяс Мухамадуллин ответил - это человек, который в контексте задачи и может принимать решения в части интеграций: аналитик, архитектор, разработчик или тимлид 🤨
Неожиданно меня увлек доклад про выбор NoSQL в кейсе про справочник налогообложения для формирования чеков в ресторанах. Запомнилось, что в этом кейсе 180 секунд оказалось достаточно, чтобы оформить заказ в киоске, на кассе или в приложении. Это был предметный и искренний рассказ о выборе NoSQL для кеширования данных заказа. Татьяна Павлюченкова поделилась ссылкой на Миро, где выложена табличка с типами таких БД и критериями выбора для этого конкретного кейса.
Был доклад Ирины Матвеевой про ТРИЗ. Рассказ о постановке задачи по ТРИЗ и о сути подхода. Из переписки в чате сохранила себе ссылку на табличку из статьи Альтшуллера Г.С. Алгоритм изобретения (1973), где в зависимости от того, что нужно изменить для решения конкретного типа задачи указаны номера методов решения. Чтобы начать решать задачу нужно понять главную полезную функцию системы. Так что вопрос «какую проблему мы решаем?» выглядит вполне вопросом по ТРИЗ.
Некоторые доклады досматривала уже после окончания конференции и тогда же дочитывала чатик, где не обошлось без очередного обмена мнениями о разделении функций СА и БА, без него теперь редко обходится 🤷♀️
Вышло так, что в прошлую субботу перед ужином снова слушала доклады. И то, и другое было полезным 🌱
👍3🔥1
Как посмотреть, что делают другие?
#инструменты #кейс
На прошедшей неделе пришлось пару раз обращаться к бенчмаркингу для выявления требований. Понадобилось поискать идеи для рабочей задачки
В моем опыте я позже прочих техник добралась до анализа приложений других компаний. Однажды в работе над вариантом CRM-системы для меня оказалось своего рода открытием, что моя система не уникальна и можно посмотреть как сделаны такие же. Когда я начинала работать, рынок еще не был настолько заполнен автоматизированными решениями. Теперь уже просто обязательно оглядеться на существующие решения, если только вы не работаете над совершенно инновационным продуктом.
В роли БА чаще всего пригождается функциональный анализ, когда рассматриваются отдельные функции приложений других компаний. Для этого бывает достаточно зайти в приложение в роли пользователя или сделать аналитическую покупку, чтобы пройти нужные шаги клиентского пути. При этом важно
1️⃣Сформулировать, что и с какой целью вы ищете. Формулировка вида "Хотим улучшить страницу", не поможет очертить границы исследования и понять, какие идеи считать улучшающими эту самую страницу. Нужно понимать для какой аудитории, с какой целью нужно анализировать варианты решения. Например, "За счет изменения функциональности и дизайна главной страницы, ожидаем привлечь N% клиентов малого бизнеса к покупке нового продукта"
2️⃣Определить компании для анализа. Это не обязательно прямые конкуренты, могут быть и компании смежных отраслей, если клиенты нанимают их на похожую работу. Если вам нужно изучить варианты бронирования жилья для поездки в отпуск, то могут пригодиться не только приложения для бронирования отелей, но и сайты авиакомпаний, которые предлагают забронировать отель в месте назначения поездки или сайты аренды квартир и апартаментов
3️⃣Определить критерии для анализа и сравнения. Выбор критериев зависит от целей анализа. Это могут быть особенности навигации по приложению, подходы к фильтрам на странице, механики привлечения внимания и пр.
4️⃣Сформулировать найденные идеи в формате, который позволит обобщить и провести сравнительный анализ идей. Например, в формате таблицы, где идеи собраны по каждому критерию, для каждой выбранной компании
5️⃣Помнить, что вы сможете получить информацию о том, какие решения выбрали другие компании, но не обязательно поймете как эти решения сделаны, почему именно они выбраны и насколько помогли достичь к цели. Вы получите идеи, но придется проверять самим подойдут ли эти идеи вашей компании и действительно ли хорошо сработают для достижения именно ваших целей
#инструменты #кейс
На прошедшей неделе пришлось пару раз обращаться к бенчмаркингу для выявления требований. Понадобилось поискать идеи для рабочей задачки
В моем опыте я позже прочих техник добралась до анализа приложений других компаний. Однажды в работе над вариантом CRM-системы для меня оказалось своего рода открытием, что моя система не уникальна и можно посмотреть как сделаны такие же. Когда я начинала работать, рынок еще не был настолько заполнен автоматизированными решениями. Теперь уже просто обязательно оглядеться на существующие решения, если только вы не работаете над совершенно инновационным продуктом.
В роли БА чаще всего пригождается функциональный анализ, когда рассматриваются отдельные функции приложений других компаний. Для этого бывает достаточно зайти в приложение в роли пользователя или сделать аналитическую покупку, чтобы пройти нужные шаги клиентского пути. При этом важно
1️⃣Сформулировать, что и с какой целью вы ищете. Формулировка вида "Хотим улучшить страницу", не поможет очертить границы исследования и понять, какие идеи считать улучшающими эту самую страницу. Нужно понимать для какой аудитории, с какой целью нужно анализировать варианты решения. Например, "За счет изменения функциональности и дизайна главной страницы, ожидаем привлечь N% клиентов малого бизнеса к покупке нового продукта"
2️⃣Определить компании для анализа. Это не обязательно прямые конкуренты, могут быть и компании смежных отраслей, если клиенты нанимают их на похожую работу. Если вам нужно изучить варианты бронирования жилья для поездки в отпуск, то могут пригодиться не только приложения для бронирования отелей, но и сайты авиакомпаний, которые предлагают забронировать отель в месте назначения поездки или сайты аренды квартир и апартаментов
3️⃣Определить критерии для анализа и сравнения. Выбор критериев зависит от целей анализа. Это могут быть особенности навигации по приложению, подходы к фильтрам на странице, механики привлечения внимания и пр.
4️⃣Сформулировать найденные идеи в формате, который позволит обобщить и провести сравнительный анализ идей. Например, в формате таблицы, где идеи собраны по каждому критерию, для каждой выбранной компании
5️⃣Помнить, что вы сможете получить информацию о том, какие решения выбрали другие компании, но не обязательно поймете как эти решения сделаны, почему именно они выбраны и насколько помогли достичь к цели. Вы получите идеи, но придется проверять самим подойдут ли эти идеи вашей компании и действительно ли хорошо сработают для достижения именно ваших целей
🔥5👍2
Что здесь интересного?
#навигация
Как и положено весной, хочу навести порядок и отряхнуть пыль с предыдущих публикаций 🧹 В марте больше всего набрали просмотров
📍Разнообразие начальных событий в BPMN
📍Нужно ли аналитику работать в Figma?
📍Сможете придумать логлайн для своей задачи?
📍Про БА и про СА (подборка)
📍Мозговой штурм (brainstorm) работает или нет?
📍Подборка про User Story и USM
📍Чашки и их свойства в разных системах
[ноябрь'23][декабрь'23][январь][февраль]
#навигация
Как и положено весной, хочу навести порядок и отряхнуть пыль с предыдущих публикаций 🧹 В марте больше всего набрали просмотров
📍Разнообразие начальных событий в BPMN
📍Нужно ли аналитику работать в Figma?
📍Сможете придумать логлайн для своей задачи?
📍Про БА и про СА (подборка)
📍Мозговой штурм (brainstorm) работает или нет?
📍Подборка про User Story и USM
📍Чашки и их свойства в разных системах
[ноябрь'23][декабрь'23][январь][февраль]
Мифы о применении опросов при выявлении требований
Есть ощущение, что в системном и бизнес-анализе опросы стали применяться чаще с приходом продуктовых подходов и более тесным знакомством с техниками UX-исследователей. Когда нужно что-то оценить количественно или получить обобщенную оценку мнения группы, то нужно приниматься за опрос. При этом есть мифы, на которые не могу смотреть без иронии
📍Быстро и относительно недорого применять, заявляет BABOK 3.0 (п.10.45.4 о преимуществах опросов). Кто хотя бы раз всерьез составлял опрос, тот понимает, что можно запросто потратить несколько дней на составление недвусмысленных формулировок вопросов и подбор вариантов ответов так, чтобы они не пересекались и были исчерпывающими. Эти формулировки должны неукоснительно отвечать целям опроса и позволять получить информацию в результате. После составления опросник нуждается в тестировании, так что придется отвлечь кого-то из коллег на проверку работоспособности и наличия ошибок в текстах. Если составитель хорошо потрудился, то респонденту не понадобится много времени на ответы, но респондента нужно в этот опрос еще завлечь и вообще убедиться, что вопросы задаются подходящей аудитории. Нужно составить такую рассылку, где вы правильно объясните цель активности и заинтересуете в прохождении. Отправить нужным адресатам и аккуратно повторить несколько раз в разных каналах коммуникации. А в остальном опросы - это и правда быстро 😉
📍Легче собирать информацию от большей аудитории, чем с помощью других техник, таких как интервью, снова убеждает нас BABOK 3.0 и не только он. Опросы и интервью совсем не нужно сравнивать. Интервью – качественное исследование поможет ответить на вопросы "как?" и "почему?". Совсем не обязательно разговаривать с каждым из многотысячной аудитории, а достаточно грамотно выбранных нескольких респондентов. Ценность интервью не связана напрямую с количеством участников. Опросы - количественные исследования отвечают на вопрос «Насколько? Как сильно? Сколько?» Опрос поможет, когда вы уже что-то знаете об объекте исследований и понимаете, что именно хотите измерить. При этом есть достаточно большая аудитория для статистической значимости. Вот тут я рассказала как ошиблась с объемом выборки и получила недостоверный результат.
📍Временами слышу, что через опрос можно получить много новых идей. А вас не удивляют вопросы вида: "Помогите нам стать лучше и напишите, что нам еще сделать?" В одном из опросов мне запомнился прямой и грубый ответ: "Просто сделайте, чтобы уже внедренное нормально работало" 🙈 Такого рода вопросы звучат как будто команде продукта не обязательно наблюдать за использованием, собирать данные, проводить интервью и пр. , а достаточно включить открытый вопрос в анкету. К тому же всегда ли вы готовы дать развернутый подробный ответ в окошке опросника, который открыли в расчете пройти за 5 мин?
Из того, что я видела по теме опросников, мне запомнился вебинар Как (не) надо составлять опросникиПолезное начинается только после 12й минуты
#инструменты #что_почитать
Есть ощущение, что в системном и бизнес-анализе опросы стали применяться чаще с приходом продуктовых подходов и более тесным знакомством с техниками UX-исследователей. Когда нужно что-то оценить количественно или получить обобщенную оценку мнения группы, то нужно приниматься за опрос. При этом есть мифы, на которые не могу смотреть без иронии
📍Быстро и относительно недорого применять, заявляет BABOK 3.0 (п.10.45.4 о преимуществах опросов). Кто хотя бы раз всерьез составлял опрос, тот понимает, что можно запросто потратить несколько дней на составление недвусмысленных формулировок вопросов и подбор вариантов ответов так, чтобы они не пересекались и были исчерпывающими. Эти формулировки должны неукоснительно отвечать целям опроса и позволять получить информацию в результате. После составления опросник нуждается в тестировании, так что придется отвлечь кого-то из коллег на проверку работоспособности и наличия ошибок в текстах. Если составитель хорошо потрудился, то респонденту не понадобится много времени на ответы, но респондента нужно в этот опрос еще завлечь и вообще убедиться, что вопросы задаются подходящей аудитории. Нужно составить такую рассылку, где вы правильно объясните цель активности и заинтересуете в прохождении. Отправить нужным адресатам и аккуратно повторить несколько раз в разных каналах коммуникации. А в остальном опросы - это и правда быстро 😉
📍Легче собирать информацию от большей аудитории, чем с помощью других техник, таких как интервью, снова убеждает нас BABOK 3.0 и не только он. Опросы и интервью совсем не нужно сравнивать. Интервью – качественное исследование поможет ответить на вопросы "как?" и "почему?". Совсем не обязательно разговаривать с каждым из многотысячной аудитории, а достаточно грамотно выбранных нескольких респондентов. Ценность интервью не связана напрямую с количеством участников. Опросы - количественные исследования отвечают на вопрос «Насколько? Как сильно? Сколько?» Опрос поможет, когда вы уже что-то знаете об объекте исследований и понимаете, что именно хотите измерить. При этом есть достаточно большая аудитория для статистической значимости. Вот тут я рассказала как ошиблась с объемом выборки и получила недостоверный результат.
📍Временами слышу, что через опрос можно получить много новых идей. А вас не удивляют вопросы вида: "Помогите нам стать лучше и напишите, что нам еще сделать?" В одном из опросов мне запомнился прямой и грубый ответ: "Просто сделайте, чтобы уже внедренное нормально работало" 🙈 Такого рода вопросы звучат как будто команде продукта не обязательно наблюдать за использованием, собирать данные, проводить интервью и пр. , а достаточно включить открытый вопрос в анкету. К тому же всегда ли вы готовы дать развернутый подробный ответ в окошке опросника, который открыли в расчете пройти за 5 мин?
Из того, что я видела по теме опросников, мне запомнился вебинар Как (не) надо составлять опросники
#инструменты #что_почитать
👍6❤1
Подборка про приоритеты
#что_почитать
Была у меня как-то задумка написать статью о методах приоритизации. План так и остался нереализованным, но я успела перебрать пару десятков статей о приоритетах и выбрать несколько полезностей. Вдруг и вам пригодится?
Здесь можно познакомиться с методами:
- RICE (Reach — охват, Impact — влияние, Confidence — достоверность, Effort — усилия)
- ICE (Impact — влияние, Confidence — уверенность, Ease — легкость реализации)
- Value vs Effort (ценность против усилия)
- Модель Кано
- Story mapping
- MoSCoW (Must, Should, Could, Won't)
- Opportunity scoring (оценка возможностей)
- Product tree (дерево продукта)
- Cost of delay (стоимость задержки)
- Buy a feature (купи функцию)
- Weighted scoring (взвешенная оценка)
- WSJF (Weighted Shortest Job First, сначала — более важная и короткая работа)
- Метод Вигерса
- Feature Bucket
📍Что делать в первую очередь? Простая приоритизация задач при помощи риса Статья о методе RICE. Есть пример, можно подсмотреть как автор работает с этим методом
📍12 методов приоритизации продуктовых целей: RICE, WSJF, KANO и прочие В статье речь о расстановке приоритетов продуктовых целей, но для пользовательских историй эти техники тоже работают. Кроме того, что есть в заголовке, речь о девяти методах
📍Определяем, что важнее: методы расстановки приоритетов в Big Data и цифровизации Big Data мне здесь показалось притянутым, в целом это статья о приоритетах без особого акцента на данных. Понравилось разделение на тактический и стратегический уровни приоритизации, а еще сравнение подходов из BABOK с подходами портфельного управления. Дополнительно к методам из предыдущих статей, здесь упомянуты метод Вигерса и Feature Bucket
📍Техники скоринга и приоритизации бэклогов Еще одна точка зрения на те же методы Story mapping, Value & Effort, MoSCoW, Kano, ICE, RICE, а еще техники оценки задач с картинками и примерами
📍Почему не удалось с первой попытки найти приоритеты? Давний пост в нашем канале с кейсом неудачного применения метода Кано и удачного применения Value vs Effort. Здесь тоже есть пара полезных ссылок на статьи о методе Кано
#что_почитать
Была у меня как-то задумка написать статью о методах приоритизации. План так и остался нереализованным, но я успела перебрать пару десятков статей о приоритетах и выбрать несколько полезностей. Вдруг и вам пригодится?
Здесь можно познакомиться с методами:
- RICE (Reach — охват, Impact — влияние, Confidence — достоверность, Effort — усилия)
- ICE (Impact — влияние, Confidence — уверенность, Ease — легкость реализации)
- Value vs Effort (ценность против усилия)
- Модель Кано
- Story mapping
- MoSCoW (Must, Should, Could, Won't)
- Opportunity scoring (оценка возможностей)
- Product tree (дерево продукта)
- Cost of delay (стоимость задержки)
- Buy a feature (купи функцию)
- Weighted scoring (взвешенная оценка)
- WSJF (Weighted Shortest Job First, сначала — более важная и короткая работа)
- Метод Вигерса
- Feature Bucket
📍Что делать в первую очередь? Простая приоритизация задач при помощи риса Статья о методе RICE. Есть пример, можно подсмотреть как автор работает с этим методом
📍12 методов приоритизации продуктовых целей: RICE, WSJF, KANO и прочие В статье речь о расстановке приоритетов продуктовых целей, но для пользовательских историй эти техники тоже работают. Кроме того, что есть в заголовке, речь о девяти методах
📍Определяем, что важнее: методы расстановки приоритетов в Big Data и цифровизации Big Data мне здесь показалось притянутым, в целом это статья о приоритетах без особого акцента на данных. Понравилось разделение на тактический и стратегический уровни приоритизации, а еще сравнение подходов из BABOK с подходами портфельного управления. Дополнительно к методам из предыдущих статей, здесь упомянуты метод Вигерса и Feature Bucket
📍Техники скоринга и приоритизации бэклогов Еще одна точка зрения на те же методы Story mapping, Value & Effort, MoSCoW, Kano, ICE, RICE, а еще техники оценки задач с картинками и примерами
📍Почему не удалось с первой попытки найти приоритеты? Давний пост в нашем канале с кейсом неудачного применения метода Кано и удачного применения Value vs Effort. Здесь тоже есть пара полезных ссылок на статьи о методе Кано
🔥6❤1👍1
Аналитик с опытом может быть новичком!
Сегодня думаю про адаптацию в новой команде. Участвую в подготовке курса для онбординга аналитиков, отсюда и #мысливслух.
Прием в новой компании и команде может оставлять впечатления очень надолго. У меня в прихожей прячется от дождя зонтик-трость с логотипом одной прекрасной компании. Мне там хорошо работалось и этот бесполезный остаток welcome-pack меня радует как старое семейное фото. К чему это я? ))
В новой команде даже самый опытный эксперт на пару дней чувствует себя новичком. Есть мнение, что эксперту онбординг не требуется. Правильно ли при адаптации полностью полагаться на экспертный опыт? Разве он поможет найти доступы в нужные системы и быстро разобраться в названиях в вашем бэклоге? Конечно, коллега с опытом рано или поздно разберется в вашей схеме работы, но какие впечатления и уровень доверия к команде у него останутся? 🤔
"Адаптация" не равно "развитие". Помнится, пару лет назад коллега в новой команде встретила меня словами "Так я же тебя знаю, твои вебинары смотрела!" (Аня, привет!👋 ) Это было приятно, что никому не нужно ничего доказывать насчет развития. Не всегда так везет. Переход в новую команду бывает похож на изучение нового языка, когда человека считают глупым, потому что он неправильно называет аббревиатуры названий отделов. И вот уже бадди дружелюбно и очень навязчиво объясняет, что "дейли – это каждый день, а диаграмма - она из квадратиков". Наверное, в таких случаях тоже может эмоционально выручать какой-нибудь зонтик с логотипом какой-то прекрасной компании )))
Какие у вас мысли об онбординге? Как вас встречали в вашей нынешней команде?
#мысливслух
Сегодня думаю про адаптацию в новой команде. Участвую в подготовке курса для онбординга аналитиков, отсюда и #мысливслух.
Прием в новой компании и команде может оставлять впечатления очень надолго. У меня в прихожей прячется от дождя зонтик-трость с логотипом одной прекрасной компании. Мне там хорошо работалось и этот бесполезный остаток welcome-pack меня радует как старое семейное фото. К чему это я? ))
В новой команде даже самый опытный эксперт на пару дней чувствует себя новичком. Есть мнение, что эксперту онбординг не требуется. Правильно ли при адаптации полностью полагаться на экспертный опыт? Разве он поможет найти доступы в нужные системы и быстро разобраться в названиях в вашем бэклоге? Конечно, коллега с опытом рано или поздно разберется в вашей схеме работы, но какие впечатления и уровень доверия к команде у него останутся? 🤔
"Адаптация" не равно "развитие". Помнится, пару лет назад коллега в новой команде встретила меня словами "Так я же тебя знаю, твои вебинары смотрела!" (Аня, привет!
Какие у вас мысли об онбординге? Как вас встречали в вашей нынешней команде?
#мысливслух
Please open Telegram to view this post
VIEW IN TELEGRAM
❤12🔥1
Нужно ли команде тратить время на ревью требований? (peer-to-peer review)
Когда работаю над большой задачей, отправляю первую версию описания требований команде и другим аналитикам с просьбой посмотреть и дать комментарии. Обычно мало надежды на развернутую обратную связь. На нее мало у кого находится время и интерес. Пока "мячик на стороне аналитика" не очень понятно зачем тратить время на какие-то задачи, которые еще не пришли в разработку. Тем не менее есть преимущества от такой траты времени
📌Остановить перфекционизм. Замечали, что чем дольше работаешь с текстом, тем больше начинаешь видеть недочетов, дополнять деталями и переставлять слова? Те кто перечитывает свои же документы через год или два, выдает "Нуу сейчас я бы сделал не так". Тем не менее разработка по этим описаниям как-то состоялась. Всегда есть, что улучшить, правда? Вопрос только, когда остановиться. Когда работа над описанием требований начинает превращаться в хождение по кругу и улучшательство, бывает полезно остановиться и кому-то из команды показать свой текст. По вопросам коллег можно заметить, где перфекционизм создал "многобукв", где пропущена важная деталь, а где неправильно расставлены акценты. Команде рано или поздно придется работать с этой информацией и чем меньше вопросов останется, тем быстрее и проще будет в разработке и тестировании
📌Исключить когнитивные искажения. Мы все вносим какие-то предположения в свою работу. У меня есть привычка делать очень детальные описание и за деталями становится сложно отследить концепцию изменений. Так бывает, когда я строю свои предположения о неизвестном в команде и добавляю детали. Предположение не всегда верно и может получиться перегруз всем известной информацией.
В одной компании я попалась на предположении, что любое изменение клиентских данных хранится в истории и можно легко найти предыдущие значения ФИО и даты рождения. Была уверена, что с чувствительными данными поступают именно так и построила вокруг этого целую фичу. Оказалось, что мой мир слишком идеален. Хорошо, что было кому посмотреть на мое решение и скорректировать☺️
📌Экспертное мнение. Если вы ходите по кругу в выборе нюансов решения, то полезно сходить за дополнительным экспертным мнением. Если несколько команд работают над связанными фичами, то ревью полезно еще и как способ обмена информацией. Для команды это возможность сберечь время на реализации не самого оптимального решения.
Самопроверка при этом не отменяется, не стоит перекладывать на команду контроль соответствия формату, терминологии и орфографических ошибок.
Можно предложить документацию на предварительное ревью и бизнесу тоже, не только команде. Потом проще проходить формальное согласование. Об этом пара слов в статье тут
Экономия времени на ревью в итоге выглядит поведением скупого, который платит дважды. В работе аналитиков тоже случаются баги и почему бы их не найти пораньше?
#инструменты #кейс #что_почитать
Когда работаю над большой задачей, отправляю первую версию описания требований команде и другим аналитикам с просьбой посмотреть и дать комментарии. Обычно мало надежды на развернутую обратную связь. На нее мало у кого находится время и интерес. Пока "мячик на стороне аналитика" не очень понятно зачем тратить время на какие-то задачи, которые еще не пришли в разработку. Тем не менее есть преимущества от такой траты времени
📌Остановить перфекционизм. Замечали, что чем дольше работаешь с текстом, тем больше начинаешь видеть недочетов, дополнять деталями и переставлять слова? Те кто перечитывает свои же документы через год или два, выдает "Нуу сейчас я бы сделал не так". Тем не менее разработка по этим описаниям как-то состоялась. Всегда есть, что улучшить, правда? Вопрос только, когда остановиться. Когда работа над описанием требований начинает превращаться в хождение по кругу и улучшательство, бывает полезно остановиться и кому-то из команды показать свой текст. По вопросам коллег можно заметить, где перфекционизм создал "многобукв", где пропущена важная деталь, а где неправильно расставлены акценты. Команде рано или поздно придется работать с этой информацией и чем меньше вопросов останется, тем быстрее и проще будет в разработке и тестировании
📌Исключить когнитивные искажения. Мы все вносим какие-то предположения в свою работу. У меня есть привычка делать очень детальные описание и за деталями становится сложно отследить концепцию изменений. Так бывает, когда я строю свои предположения о неизвестном в команде и добавляю детали. Предположение не всегда верно и может получиться перегруз всем известной информацией.
В одной компании я попалась на предположении, что любое изменение клиентских данных хранится в истории и можно легко найти предыдущие значения ФИО и даты рождения. Была уверена, что с чувствительными данными поступают именно так и построила вокруг этого целую фичу. Оказалось, что мой мир слишком идеален. Хорошо, что было кому посмотреть на мое решение и скорректировать
📌Экспертное мнение. Если вы ходите по кругу в выборе нюансов решения, то полезно сходить за дополнительным экспертным мнением. Если несколько команд работают над связанными фичами, то ревью полезно еще и как способ обмена информацией. Для команды это возможность сберечь время на реализации не самого оптимального решения.
Самопроверка при этом не отменяется, не стоит перекладывать на команду контроль соответствия формату, терминологии и орфографических ошибок.
Можно предложить документацию на предварительное ревью и бизнесу тоже, не только команде. Потом проще проходить формальное согласование. Об этом пара слов в статье тут
Экономия времени на ревью в итоге выглядит поведением скупого, который платит дважды. В работе аналитиков тоже случаются баги и почему бы их не найти пораньше?
#инструменты #кейс #что_почитать
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7❤2
Что здесь есть о выявлении требований?
Собиралась сделать очередной навигационный пост и пока перелистывала старые посты пришла к другой идее.
Когда-то я делала карточку с памяткой по техникам выявления требований и с тех пор ухитрилась написать о многих из них. Собрала здесь ссылки
🔅Интервью
Про ошибки при проведении интервью с пользователями
Какие вопросы?
Интервью на удаленке
🔅Бенчмаркинг
Как посмотреть, что делают другие?
🔅Прототипирование
Что такое прототипы и какими они бывают?
Каркасное проектирование или wireframes
🔅Анализ процессов
Причины использовать Process Mining
Способы использования BPMN
Стартовые события, сквозные процессы, process mining...
🔅Опрос
Мифы о применении опросов при выявлении требований
🔅Мозговой штурм
Мозговой штурм (brainstorm) работает или нет?
#навигация #что_почитать
Собиралась сделать очередной навигационный пост и пока перелистывала старые посты пришла к другой идее.
Когда-то я делала карточку с памяткой по техникам выявления требований и с тех пор ухитрилась написать о многих из них. Собрала здесь ссылки
🔅Интервью
Про ошибки при проведении интервью с пользователями
Какие вопросы?
Интервью на удаленке
🔅Бенчмаркинг
Как посмотреть, что делают другие?
🔅Прототипирование
Что такое прототипы и какими они бывают?
Каркасное проектирование или wireframes
🔅Анализ процессов
Причины использовать Process Mining
Способы использования BPMN
Стартовые события, сквозные процессы, process mining...
🔅Опрос
Мифы о применении опросов при выявлении требований
🔅Мозговой штурм
Мозговой штурм (brainstorm) работает или нет?
#навигация #что_почитать
👍6🤩3
Быстрее, лучше, дешевле. Девять методов реинжиниринга бизнес-процессов
М. Хаммер, Л. Хершман. Год издания: 2010
Когда вы читаете все, что еще год назад сохранили списком в Notion или еще где-то? Я вспоминаю о своем списке, когда оказываюсь где-то в ожидании или в пути, в остальное время всегда находится что-то ужасно срочное или интересное☺️
Если бы не 24 часа поездки в поезде до Кисловодска и обратно, то не справилась бы с этой книгой. Это очень обстоятельный рассказ на несколько сотен страниц. Авторы аккуратно резюмируют итоги каждого раздела, приводят огромное количество примеров. Эта самая обстоятельность - одновременно и плюс и минус книги. С одной стороны интересно читать примеры, а с другой их очень много и не всегда они детально раскрыты, так что не понимаешь какой вывод ожидался из этого текста. На мой взгляд, получилось не слишком увлекательное чтение с парой полезностей.
О чем книга?
Речь о концепции сквозного процесса и о том, что потребуется от руководителя и от специалистов, чтобы его внедрить. Как процессный подход позволяет достигать целей, развивать бизнес и иметь конкурентное преимущество на рынке. Чтобы получить такое преимущество нужно научиться видеть процесс со всеми его шагами и связями. А еще иметь руководителей, которые могут видеть все шаги, но не только сферу ответственности какого-то участка или отдела.
Издание вышло почти полтора десятка лет назад и вряд ли покажутся новыми рассуждения о культуре KPI или общее описание процессной культуры в компаниях. Эти мысли стали приходить с первых же слов предисловия к книге.
Что может быть полезно?
На примерах посмотреть как отличаются в процессах шаги добавляющие ценность и прочие операционные, административные шаги. Как выглядит процесс, где только 3 шага добавляют ценность, а 15 – передача информации из рук в руки.
Мне понравился пример с процессом обрезки деревьев. Чтобы снизить количество аварий на линиях электропередач нужно было построить процесс обрезки деревьев и следить за его эффективностью. Хорошо передан контекст исследования проблемы и поиска решений.
Полезно обобщение семи принципов проектирования:
• какие операции будут выполняться;
• будут ли они выполняться и при каких условиях;
• кто будет их выполнять;
• когда это будет происходить;
• где они будут выполняться;
• насколько точно они будут выполняться;
• какая информация будет при этом использоваться.
Глава о показателях эффективности. Мне понравился прием, с перечислением "грехов", которые могут привести к ошибкам в выборе системы показателей. Оставлю их здесь, а вы сами читайте в книге или предполагайте, как они влияют на выбор метрик процессов:
• тщеславие;
• самолюбование;
• лень;
• нежелание масштабно мыслить;
• бессмысленность;
• легкомыслие.
Кому может быть полезно?
Создалось впечатление, что в книге слишком мало конкретики для начинающего специалиста, который еще не сталкивался с запутанными процессами крупных предприятий и не разобрался в цепочках создания ценности.
Эксперту с опытом в построении бизнес-процессов может быть интересно познакомиться с описанием принципов проектирования, описанием организационных изменений и некоторыми примерами, как иллюстрацией и дополнением к собственному опыту.
#книжки
М. Хаммер, Л. Хершман. Год издания: 2010
Когда вы читаете все, что еще год назад сохранили списком в Notion или еще где-то? Я вспоминаю о своем списке, когда оказываюсь где-то в ожидании или в пути, в остальное время всегда находится что-то ужасно срочное или интересное
Если бы не 24 часа поездки в поезде до Кисловодска и обратно, то не справилась бы с этой книгой. Это очень обстоятельный рассказ на несколько сотен страниц. Авторы аккуратно резюмируют итоги каждого раздела, приводят огромное количество примеров. Эта самая обстоятельность - одновременно и плюс и минус книги. С одной стороны интересно читать примеры, а с другой их очень много и не всегда они детально раскрыты, так что не понимаешь какой вывод ожидался из этого текста. На мой взгляд, получилось не слишком увлекательное чтение с парой полезностей.
О чем книга?
Речь о концепции сквозного процесса и о том, что потребуется от руководителя и от специалистов, чтобы его внедрить. Как процессный подход позволяет достигать целей, развивать бизнес и иметь конкурентное преимущество на рынке. Чтобы получить такое преимущество нужно научиться видеть процесс со всеми его шагами и связями. А еще иметь руководителей, которые могут видеть все шаги, но не только сферу ответственности какого-то участка или отдела.
Издание вышло почти полтора десятка лет назад и вряд ли покажутся новыми рассуждения о культуре KPI или общее описание процессной культуры в компаниях. Эти мысли стали приходить с первых же слов предисловия к книге.
Что может быть полезно?
На примерах посмотреть как отличаются в процессах шаги добавляющие ценность и прочие операционные, административные шаги. Как выглядит процесс, где только 3 шага добавляют ценность, а 15 – передача информации из рук в руки.
Мне понравился пример с процессом обрезки деревьев. Чтобы снизить количество аварий на линиях электропередач нужно было построить процесс обрезки деревьев и следить за его эффективностью. Хорошо передан контекст исследования проблемы и поиска решений.
Полезно обобщение семи принципов проектирования:
• какие операции будут выполняться;
• будут ли они выполняться и при каких условиях;
• кто будет их выполнять;
• когда это будет происходить;
• где они будут выполняться;
• насколько точно они будут выполняться;
• какая информация будет при этом использоваться.
Глава о показателях эффективности. Мне понравился прием, с перечислением "грехов", которые могут привести к ошибкам в выборе системы показателей. Оставлю их здесь, а вы сами читайте в книге или предполагайте, как они влияют на выбор метрик процессов:
• тщеславие;
• самолюбование;
• лень;
• нежелание масштабно мыслить;
• бессмысленность;
• легкомыслие.
Кому может быть полезно?
Создалось впечатление, что в книге слишком мало конкретики для начинающего специалиста, который еще не сталкивался с запутанными процессами крупных предприятий и не разобрался в цепочках создания ценности.
Эксперту с опытом в построении бизнес-процессов может быть интересно познакомиться с описанием принципов проектирования, описанием организационных изменений и некоторыми примерами, как иллюстрацией и дополнением к собственному опыту.
#книжки
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3🔥2
Цундоку и статьи про стейкхолдеров
Узнала японское слово, оно означает накопление книг, которые никогда не смогут быть прочитаны за всю жизнь их владельца. Наверняка это слово как-то по-японски имеет кучу нюансов, передаю как поняла с чужих слов. У меня такое со статьями, видео, книгами – везде сплошное цундоку. Хорошо, что можно делиться информацией, это мотивирует и почитать, и поделиться, чтобы списки статей не пропадали зря😎
Разобрала материалы про заинтересованные стороны, делюсь
🌱Эффективное управление отношениями со стейкхолдерами Рассказ от самых основ терминологии, описание основных инструментов RACI, карта заинтересованных сторон, матрица влияние-интерес. Все неплохо, но если вы уже в теме, то можно заскучать.
🌱Бизнес-аналитик — мастер переговоров или как не сойти с ума, работая с требованиями Это рассказ BI-аналитика о том, с чем приходится сталкиваться при проектировании дашбордов. Уверена, что многие из нас не думали о дашбордах с точки зрения переговоров с заказчиками
🌱Работа с заинтересованными лицами на проекте Эта статья состоит из рецептов по взаимодействию с заинтересованными сторонами, я насчитала их 29. Мне понравился совет побольше общаться один на один, даже если заинтересованных несколько. Тоже часто применяю такой подход, потому что проще уточнить мнение человека, когда он свободен от влияния группового мышления, имеет возможность высказаться и быть выслушанным. Только для этого вам нужно время и умение слушать и слышать.
🎥Что и как спросить у бизнеса, чтобы проработать ИТ-решение Давний стрим с весьма честными рассуждениями об отношениях между ИТ и бизнесом, а еще с шаблонами того, чем следует поинтересоваться для успеха будущего ИТ-продукта. Слушать сложно, но и назвать бесполезным тоже сложно
🌱Цена термина "заказчик" не удержалась и добавила в подборку свое небольшое рассуждение о неполном понимание термина "заинтересованная сторона" и как оно влияет на сроки разработки продукта
🌱Кто такие «заинтересованные стороны» и в каком случае для бизнеса от них больше пользы, чем проблем? (на основе кейса) Это о заинтересованных с точки зрения маркетинга. Интересно перечислены ожидания разных сторон
#что_почитать
Узнала японское слово, оно означает накопление книг, которые никогда не смогут быть прочитаны за всю жизнь их владельца. Наверняка это слово как-то по-японски имеет кучу нюансов, передаю как поняла с чужих слов. У меня такое со статьями, видео, книгами – везде сплошное цундоку. Хорошо, что можно делиться информацией, это мотивирует и почитать, и поделиться, чтобы списки статей не пропадали зря
Разобрала материалы про заинтересованные стороны, делюсь
🌱Эффективное управление отношениями со стейкхолдерами Рассказ от самых основ терминологии, описание основных инструментов RACI, карта заинтересованных сторон, матрица влияние-интерес. Все неплохо, но если вы уже в теме, то можно заскучать.
🌱Бизнес-аналитик — мастер переговоров или как не сойти с ума, работая с требованиями Это рассказ BI-аналитика о том, с чем приходится сталкиваться при проектировании дашбордов. Уверена, что многие из нас не думали о дашбордах с точки зрения переговоров с заказчиками
🌱Работа с заинтересованными лицами на проекте Эта статья состоит из рецептов по взаимодействию с заинтересованными сторонами, я насчитала их 29. Мне понравился совет побольше общаться один на один, даже если заинтересованных несколько. Тоже часто применяю такой подход, потому что проще уточнить мнение человека, когда он свободен от влияния группового мышления, имеет возможность высказаться и быть выслушанным. Только для этого вам нужно время и умение слушать и слышать.
🎥Что и как спросить у бизнеса, чтобы проработать ИТ-решение Давний стрим с весьма честными рассуждениями об отношениях между ИТ и бизнесом, а еще с шаблонами того, чем следует поинтересоваться для успеха будущего ИТ-продукта. Слушать сложно, но и назвать бесполезным тоже сложно
🌱Цена термина "заказчик" не удержалась и добавила в подборку свое небольшое рассуждение о неполном понимание термина "заинтересованная сторона" и как оно влияет на сроки разработки продукта
🌱Кто такие «заинтересованные стороны» и в каком случае для бизнеса от них больше пользы, чем проблем? (на основе кейса) Это о заинтересованных с точки зрения маркетинга. Интересно перечислены ожидания разных сторон
#что_почитать
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6🔥1
Правда, что аналитик должен знать UML?
Правда, что знание UML это must have для аналитика? – это был вопрос ко мне от коллеги, которая задумалась перейти из QA в анализ. Я даже вздрогнула от неожиданности и присмотрелась не провокация ли? Мол поспорим с взрослым человеком об инструментах двадцатилетней давности. Нет, это было искренне
Автор вопроса вряд ли в курсе, что холивар о жизнеспособности UML идет уже несколько лет и можно почитать про то как UML умер, про то как он тянет в прошлое и наоборот про то, как много теряется, если не использовать. А больше всего публикаций с руководствами по элементам нотации отдельных видов диаграмм UML: диаграммы последовательности, классов, вариантов использования, деятельности. Это потому, что полные визуальные модели со всеми уровнями представления мало где применяются, а отдельные элементы вполне находят себе место
Если говорить о must have для аналитика, то это системное мышление. Речь не о том, чтобы на любой запрос тут же сказать в какой системе нужно будет добавить кнопку или сколько сервисов добавить. Это об умении увидеть взаимодействующие элементы в заданном контексте. Изучать UML именно как средство построения модели системы, может быть полезным, чтобы развить способность системно видеть вещи
В моих первых документах трогательно изображались диаграммы вариантов использования с человечками, будто летящими на воздушных шариках, как на картинке к этому посту. Важно было показать знания UML. Поверхностное знание легко приобретается и легко уходит
Аналитику нужно знать хотя бы одну из нотаций. Вот только особенность нашей работы в том, что при переключении между задачами, проектами и работами на первый план каждый раз выходят разные инструменты, а некоторые навыки без применения могут теряться. Скажем, за последние 15 лет мне так и не повезло толком работать с UML, максимум, что вижу – sequence diagram. UML вполне жив и имеет своих поклонников, но я бы не посоветовала изучать все виды диаграмм, если не планируете применять в работе
#мысливслух #что_почитать
Правда, что знание UML это must have для аналитика? – это был вопрос ко мне от коллеги, которая задумалась перейти из QA в анализ. Я даже вздрогнула от неожиданности и присмотрелась не провокация ли? Мол поспорим с взрослым человеком об инструментах двадцатилетней давности. Нет, это было искренне
Автор вопроса вряд ли в курсе, что холивар о жизнеспособности UML идет уже несколько лет и можно почитать про то как UML умер, про то как он тянет в прошлое и наоборот про то, как много теряется, если не использовать. А больше всего публикаций с руководствами по элементам нотации отдельных видов диаграмм UML: диаграммы последовательности, классов, вариантов использования, деятельности. Это потому, что полные визуальные модели со всеми уровнями представления мало где применяются, а отдельные элементы вполне находят себе место
Если говорить о must have для аналитика, то это системное мышление. Речь не о том, чтобы на любой запрос тут же сказать в какой системе нужно будет добавить кнопку или сколько сервисов добавить. Это об умении увидеть взаимодействующие элементы в заданном контексте. Изучать UML именно как средство построения модели системы, может быть полезным, чтобы развить способность системно видеть вещи
В моих первых документах трогательно изображались диаграммы вариантов использования с человечками, будто летящими на воздушных шариках, как на картинке к этому посту. Важно было показать знания UML. Поверхностное знание легко приобретается и легко уходит
Аналитику нужно знать хотя бы одну из нотаций. Вот только особенность нашей работы в том, что при переключении между задачами, проектами и работами на первый план каждый раз выходят разные инструменты, а некоторые навыки без применения могут теряться. Скажем, за последние 15 лет мне так и не повезло толком работать с UML, максимум, что вижу – sequence diagram. UML вполне жив и имеет своих поклонников, но я бы не посоветовала изучать все виды диаграмм, если не планируете применять в работе
#мысливслух #что_почитать
👍4🔥3❤1🤩1
Повод больше общаться или ужас?
Как вы реагируете, когда видите реализацию сильно мимо вашей постановки или ТЗ? Я со временем прошла разные стадии: 1. ужас, я что-то неправильно сделала; 2. ужас, какие все ленивые, я-то все четко написала; 3. ужас, как люди разучились читать... Сейчас прихожу к точке зрения без слова "ужас"
Большие документы по заданной структуре совсем неплохая штука для тех, кто их пишет. Структура может играть роль чек-листа и задавать ход мысли, особенно если аналитику действительно понятна цель каждого раздела. Для читающих – это может быть полезным справочным материалом, если он хорошо понимает, где и что найти. Полезно, если в базе знаний останется не только сама постановка задачи, но и контекст задачи и причины выбора конкретного решения.
Здесь очень большое искушение пройтись на тему текстов, которые больше запутывают, чем дают информацию, но я об этом уже писала тут, сейчас речь о другом.
Со стороны аналитика документ с постановкой задачи используется как завершение некоего этапа и способ передачи ответственности следующему исполнителю. Так это когда-то и было задумано. Для команды является ли конечным результатом постановка задачи или документ? Всегда ли можно снять с себя ответственность за результат перекладыванием информации на какой-либо носитель? Существует ли в действительности формат изложения одинаково понятный любой аудитории во всех нюансах?
Однажды, я принесла с конференции забавный рецепт привлечения внимания к тексту в постановке задачи. По рецепту рекомендовалось добавить в текст пару нетипичных слов и попросить команду найти эти слова. Например, слово "Чебурашка". Знаете что обнаружилось? Слово нашли те, кто и без него обычно внимательно смотрел документы, а остальных никакими чебурашками не заманишь. Потому что, если нет мотивации разбираться в задаче, то не работают ни записи видео, ни документы с картинками, ни доски со стикерами.
Кроме вопросов мотивации, у читателей документа срабатывают те же механизмы когнитивных искажений, что свойственны всем нам. Отсекается то, что кажется неважным для задачи, теряется непонятное, насмотренность подсказывает какую-то интерпретацию "между строк"... Вот тут на Хабре еще одно мнение о том как получается результат не по ТЗ. Если коротко, то просто люди устают читать для них неважное и забивают на детали 🤷♀️
Чтобы неважное стало важным, каждому участнику нужно понимание результата и своего участия в нем. Не всегда из роли аналитика можно повлиять на всю команду таким образом. Зато можно перестать ужасаться и думать, что документ, таблица, задача или картинка сами по себе могут гарантировать общее однозначное понимание. Можно попробовать после подготовки требований больше общаться с командой, много отвечать на вопросы и устраивать обзорные встречи, чтобы донести информацию. Но и это не точно😎
#мысливслух
Как вы реагируете, когда видите реализацию сильно мимо вашей постановки или ТЗ? Я со временем прошла разные стадии: 1. ужас, я что-то неправильно сделала; 2. ужас, какие все ленивые, я-то все четко написала; 3. ужас, как люди разучились читать... Сейчас прихожу к точке зрения без слова "ужас"
Большие документы по заданной структуре совсем неплохая штука для тех, кто их пишет. Структура может играть роль чек-листа и задавать ход мысли, особенно если аналитику действительно понятна цель каждого раздела. Для читающих – это может быть полезным справочным материалом, если он хорошо понимает, где и что найти. Полезно, если в базе знаний останется не только сама постановка задачи, но и контекст задачи и причины выбора конкретного решения.
Здесь очень большое искушение пройтись на тему текстов, которые больше запутывают, чем дают информацию, но я об этом уже писала тут, сейчас речь о другом.
Со стороны аналитика документ с постановкой задачи используется как завершение некоего этапа и способ передачи ответственности следующему исполнителю. Так это когда-то и было задумано. Для команды является ли конечным результатом постановка задачи или документ? Всегда ли можно снять с себя ответственность за результат перекладыванием информации на какой-либо носитель? Существует ли в действительности формат изложения одинаково понятный любой аудитории во всех нюансах?
Однажды, я принесла с конференции забавный рецепт привлечения внимания к тексту в постановке задачи. По рецепту рекомендовалось добавить в текст пару нетипичных слов и попросить команду найти эти слова. Например, слово "Чебурашка". Знаете что обнаружилось? Слово нашли те, кто и без него обычно внимательно смотрел документы, а остальных никакими чебурашками не заманишь. Потому что, если нет мотивации разбираться в задаче, то не работают ни записи видео, ни документы с картинками, ни доски со стикерами.
Кроме вопросов мотивации, у читателей документа срабатывают те же механизмы когнитивных искажений, что свойственны всем нам. Отсекается то, что кажется неважным для задачи, теряется непонятное, насмотренность подсказывает какую-то интерпретацию "между строк"... Вот тут на Хабре еще одно мнение о том как получается результат не по ТЗ. Если коротко, то просто люди устают читать для них неважное и забивают на детали 🤷♀️
Чтобы неважное стало важным, каждому участнику нужно понимание результата и своего участия в нем. Не всегда из роли аналитика можно повлиять на всю команду таким образом. Зато можно перестать ужасаться и думать, что документ, таблица, задача или картинка сами по себе могут гарантировать общее однозначное понимание. Можно попробовать после подготовки требований больше общаться с командой, много отвечать на вопросы и устраивать обзорные встречи, чтобы донести информацию. Но и это не точно
#мысливслух
Please open Telegram to view this post
VIEW IN TELEGRAM
❤5👍4
О чем говорят продуктовые аналитики?
Стало интересно заглянуть в смежную сферу знаний и это любопытство привело меня вчера на конференцию Aha!'24
Здесь было много рукопожатий, стендов от партнеров, пирожков, лаунж-зон, где шло общение, и не очень много людей в залах на докладах. Народ собрался общаться.
Я очень грустила без программы конференции в каком-то удобном виде. Одновременно шли три стрима докладов и еще два с воркшопами, консультациями и прочими штуками, не хватало удобной карты перед глазами. Но это мне не помешало послушать 8 докладов😎
Послушала доклад аналитика из 2ГИС с рассказом как пришли к лаконичному решению, чтобы заполнить снимками зданий карточки объектов на карте. Придумали игровую технику для активных пользователей, они могли получать задания в телеграм-боте и туда же отправлять фото. Дальше шел рассказ о модерации этого контента. Очень интересно было послушать. Для себя отметила в докладе, что процент конверсии подписок на бота в выполненные задания составил 5%, но и эти 5% решают поставленную задачу
Привлек доклад с названием "Как микро-командой аналитиков сопровождать сотни запусков фичей и не потерять фокус и скорость". Пока шел рассказ об организации задач, диаграммах в Jira и настройке инфраструктуры я совсем уже было разочаровалась. Потом началось интересное про эмуляцию изменения метрик на основании вычислительных методов. Вместо дорогого a/б – теста. А дальше предложение серьезнее выбирать гипотезы для исследований и вывод "Экономьте на пустых идеях, а не на аналитиках", то есть если не тратить время на заведомо ненужные задачи, то и с рабочими руками будет проще. Мне фраза так понравилось, что я ее тут же записала
Конечно, много говорили об a/б – тестах, ML и AI, метриках и гипотезах, продуктовых стратегиях и роли продакта. Я обогатилась новыми для меня терминами, например: Customer Effort Score (подобнее об этой метрике тут), Difference-in-difference (об этом статистическом методе нашлось тут).
Было забавно ходить с бейджиком, где написано Junior. Это не про возраст и не про знания, так назывался тариф моего билета. У меня давно этого слова не появляется на бейджах и было даже приятно, что так удачно заглянула к продуктовым аналитикам 🌱
#мысливслух #конференции
Стало интересно заглянуть в смежную сферу знаний и это любопытство привело меня вчера на конференцию Aha!'24
Здесь было много рукопожатий, стендов от партнеров, пирожков, лаунж-зон, где шло общение, и не очень много людей в залах на докладах. Народ собрался общаться.
Я очень грустила без программы конференции в каком-то удобном виде. Одновременно шли три стрима докладов и еще два с воркшопами, консультациями и прочими штуками, не хватало удобной карты перед глазами. Но это мне не помешало послушать 8 докладов
Послушала доклад аналитика из 2ГИС с рассказом как пришли к лаконичному решению, чтобы заполнить снимками зданий карточки объектов на карте. Придумали игровую технику для активных пользователей, они могли получать задания в телеграм-боте и туда же отправлять фото. Дальше шел рассказ о модерации этого контента. Очень интересно было послушать. Для себя отметила в докладе, что процент конверсии подписок на бота в выполненные задания составил 5%, но и эти 5% решают поставленную задачу
Привлек доклад с названием "Как микро-командой аналитиков сопровождать сотни запусков фичей и не потерять фокус и скорость". Пока шел рассказ об организации задач, диаграммах в Jira и настройке инфраструктуры я совсем уже было разочаровалась. Потом началось интересное про эмуляцию изменения метрик на основании вычислительных методов. Вместо дорогого a/б – теста. А дальше предложение серьезнее выбирать гипотезы для исследований и вывод "Экономьте на пустых идеях, а не на аналитиках", то есть если не тратить время на заведомо ненужные задачи, то и с рабочими руками будет проще. Мне фраза так понравилось, что я ее тут же записала
Конечно, много говорили об a/б – тестах, ML и AI, метриках и гипотезах, продуктовых стратегиях и роли продакта. Я обогатилась новыми для меня терминами, например: Customer Effort Score (подобнее об этой метрике тут), Difference-in-difference (об этом статистическом методе нашлось тут).
Было забавно ходить с бейджиком, где написано Junior. Это не про возраст и не про знания, так назывался тариф моего билета. У меня давно этого слова не появляется на бейджах и было даже приятно, что так удачно заглянула к продуктовым аналитикам 🌱
#мысливслух #конференции
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥2❤1👍1
Документация и виды требований
На прошлой неделе организаторы Flow начали выкладывать доклады с весенней конференции и начали с Сожгите ваши системные требования. Пользовательские требования — ключ к успешному продукту. Когда-то я писала об этом докладе в посте с впечатлениями о Flow
Тема документирования завела меня в список недавно отмеченных статей на близкие темы. Делюсь статьями и мнением
📍Как писать требования и документацию к проекту. Полный гайд с шаблоном документации и примерами заполнения Автор поясняет, что это статья в помощь начинающим. Всегда интересно посмотреть примеры чьих-то задач, здесь это как раз есть: примеры документов и как они заполнены. К этой статье мне не хватило пояснения к процессу производства, на каких шагах и для какой аудитории рождаются эти документы. Если вы делаете первые шаги в анализе, то учитывайте, что в статье изложена не общая практика, а подход конкретной команды
📍Нужно ли писать документацию? Это в основном сторителлинг с описанием сценариев, когда даже не самая лучшая документация может сберечь время команды. Не думаю, что опытные аналитики найдут что-то новое, описаны известные боли
📍Технические задания и IT-системы: разбираемся, как ожидания мэтчить с реальностью Еще один пример опыта конкретной команды, где информацию оформляют в некоей смеси каркасного макета и слайдов презентации. Не советую считать такой формат гарантией полного понимания требований всеми участниками, тем не менее в индустрии такие варианты встречаются. Мне приходилось в таком участвовать и получать нечто похожее на согласование
📍Уж послала, так послала: словосочетания-паразиты в технических текстах и 17 вредных советов для тех, кто проверяет документацию и технические тексты Две статьи одного и того же автора о стиле высказываний в комментариях и текстах технической документации. Местами выглядит перфекционизмом, но мнение интересное
#что_почитать
На прошлой неделе организаторы Flow начали выкладывать доклады с весенней конференции и начали с Сожгите ваши системные требования. Пользовательские требования — ключ к успешному продукту. Когда-то я писала об этом докладе в посте с впечатлениями о Flow
Тема документирования завела меня в список недавно отмеченных статей на близкие темы. Делюсь статьями и мнением
📍Как писать требования и документацию к проекту. Полный гайд с шаблоном документации и примерами заполнения Автор поясняет, что это статья в помощь начинающим. Всегда интересно посмотреть примеры чьих-то задач, здесь это как раз есть: примеры документов и как они заполнены. К этой статье мне не хватило пояснения к процессу производства, на каких шагах и для какой аудитории рождаются эти документы. Если вы делаете первые шаги в анализе, то учитывайте, что в статье изложена не общая практика, а подход конкретной команды
📍Нужно ли писать документацию? Это в основном сторителлинг с описанием сценариев, когда даже не самая лучшая документация может сберечь время команды. Не думаю, что опытные аналитики найдут что-то новое, описаны известные боли
📍Технические задания и IT-системы: разбираемся, как ожидания мэтчить с реальностью Еще один пример опыта конкретной команды, где информацию оформляют в некоей смеси каркасного макета и слайдов презентации. Не советую считать такой формат гарантией полного понимания требований всеми участниками, тем не менее в индустрии такие варианты встречаются. Мне приходилось в таком участвовать и получать нечто похожее на согласование
📍Уж послала, так послала: словосочетания-паразиты в технических текстах и 17 вредных советов для тех, кто проверяет документацию и технические тексты Две статьи одного и того же автора о стиле высказываний в комментариях и текстах технической документации. Местами выглядит перфекционизмом, но мнение интересное
#что_почитать
👍2
Не будет второго шанса произвести первое впечатление
Эту фразу от Коко Шанель можно применить в многих историях, я решила ее применить к истории про резюме. В последнее время через мои руки прошло несколько резюме и друзья-коллеги тоже поделились впечатлениями из своего опыта. Не хочу отнимать хлеб у тех, кто постоянно работает в сфере найма и карьерных консультаций, но не могу не поделиться впечатлениями. Резюме и сопроводительное письмо – это как раз первое впечатление от вашего профессионализма.
Если в резюме неправильно назван рабочий инструмент или методика, это может выглядеть так, будто автор в глаза не видел, то о чем пишет. У нанимающих менеджеров опыт может быть разным. Коллеги в нанимающих командах по несколько часов в день проводят в собеседованиях и при этом никто не останавливает задачи, в которых они менеджеры или эксперты. Когда предыдущий кандидат с грубыми опечатками в резюме показал себя не лучшим образом, будет ли интересно еще раз дать кому-то шанс?
Кто участвует в найме, наверное, начинает сочувствовать своему учителю литературы. Учителю приходилось десятки раз в день читать про "луч света в темном царстве" или что мы там еще списывали друг у друга и у Добролюбова? Проверьте, на всякий случай нет ли у вас в резюме фразы "аналитический склад ума, ответственность и внимание к деталям"? Это клише содержится в таком количестве резюме, что ни одно из них уже не украсит. Особенно в сочетании с опечатками. Даже если у кандидата и правда аналитический склад ума😎
В общем, лучше не списывать фразы из резюме у коллег и внимательно проверять опечатки. Делюсь парой вариантов досадных неточностей:
📍кандидат сообщает, что три года работает в индустрии и знает Githab(Видимо, это Github)
📍работал с гибридной распределенной базой данных (Кafka)(Kafka меньше всего можно назвать базой данных)
📍интересуюсь Phyton (Лучше интересоваться Python)
📍Gif (система контроля версий) (Видимо, это про Git)
📍нотация описания процессов UML(UML- это универсальный язык моделирования, а не нотация для описания процессов)
📍BPMN-система(Системы управления процессами – это BPMS, BPMN – это обозначение нотации)
#мысливслух #карьера
Эту фразу от Коко Шанель можно применить в многих историях, я решила ее применить к истории про резюме. В последнее время через мои руки прошло несколько резюме и друзья-коллеги тоже поделились впечатлениями из своего опыта. Не хочу отнимать хлеб у тех, кто постоянно работает в сфере найма и карьерных консультаций, но не могу не поделиться впечатлениями. Резюме и сопроводительное письмо – это как раз первое впечатление от вашего профессионализма.
Если в резюме неправильно назван рабочий инструмент или методика, это может выглядеть так, будто автор в глаза не видел, то о чем пишет. У нанимающих менеджеров опыт может быть разным. Коллеги в нанимающих командах по несколько часов в день проводят в собеседованиях и при этом никто не останавливает задачи, в которых они менеджеры или эксперты. Когда предыдущий кандидат с грубыми опечатками в резюме показал себя не лучшим образом, будет ли интересно еще раз дать кому-то шанс?
Кто участвует в найме, наверное, начинает сочувствовать своему учителю литературы. Учителю приходилось десятки раз в день читать про "луч света в темном царстве" или что мы там еще списывали друг у друга и у Добролюбова? Проверьте, на всякий случай нет ли у вас в резюме фразы "аналитический склад ума, ответственность и внимание к деталям"? Это клише содержится в таком количестве резюме, что ни одно из них уже не украсит. Особенно в сочетании с опечатками. Даже если у кандидата и правда аналитический склад ума
В общем, лучше не списывать фразы из резюме у коллег и внимательно проверять опечатки. Делюсь парой вариантов досадных неточностей:
📍кандидат сообщает, что три года работает в индустрии и знает Githab
📍работал с гибридной распределенной базой данных (Кafka)
📍интересуюсь Phyton
📍Gif (система контроля версий)
📍нотация описания процессов UML
📍BPMN-система
#мысливслух #карьера
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7
Как работает шаблон документа?
"Какой взять шаблон?", - вопрос часто звучит, когда аналитик принимается за задачу. В инфопространстве коллеги активно делятся шаблонами. Только в одном из каналов с полезностями для СА и БА обнаружилось 73 ссылки на статьи с шаблонами документов. Когда в задаче не требуется следование конкретному стандарту, обращаются к шаблонам из открытых источников для экономии сил и времени. Вот только можно зря потратить много часов, если безусловно следовать шаблону без понимания теории и практики его применения.
Сам по себе шаблон не гарантирует качественный анализ. Лучше всего работают шаблоны, которые вы сами придумали в своей команде с учетом специфики именно ваших задач. Это похоже на шпаргалку, которую вы составили сами и хорошо понимаете где в ней искать ответ на конкретный вопрос экзамена. Шпаргалка другого студента не будет так хорошо работать в вашем случае, тем более, если она к какому-то другому экзамену.
Например, в одном из шаблонов мне встретился раздел с PESTEL-анализом. Если не понимать, что это за техника и для чего этот раздел, то заполнение потребует времени. Действительно ли будет важен анализ политических, социальных, экономических, экологических факторов в проекте по разработке нового отчета для вашего руководителя? Если формально заполнять разделы, то шаблон может превратиться в пожирателя времени
Шаблон полезен, когда у аналитика есть понимание, что он в нем ищет. Если на новом месте работы обнаружатся шаблоны документов – будет проще ориентироваться в ожиданиях от вашей работы. Когда есть простор в выборе структуры документа – шаблоны подскажут идеи из опыта разных команд. Если вы придумали шаблон сами – получится чек-лист для вашей работы в текущих задачах, но это не обязательно означает, что он выручит и любого другого аналитика.
Делюсь примерами, которые в последнее время попадали в поле зрения. В этом списке нет ни полноты, ни особой логики. Просто небольшая иллюстрация к теме поста.
📍Формат BRD и FSD (ENG)
📍Как писать требования и документацию к проекту. Полный гайд с шаблоном документации и примерами заполнения
📍Что такое бизнес-требования и как с ними не бороться (в последнем разделе статьи структура документа)
📍Артефакты аналитика: документы и техники
📍Как писать требования к проекту. Шаблон документации
📍Стандарты и шаблоны для ТЗ на разработку ПО (обзор форматов, соответственно разным стандартов, со ссылками на примеры)
#мысливслух #что_почитать #инструменты
"Какой взять шаблон?", - вопрос часто звучит, когда аналитик принимается за задачу. В инфопространстве коллеги активно делятся шаблонами. Только в одном из каналов с полезностями для СА и БА обнаружилось 73 ссылки на статьи с шаблонами документов. Когда в задаче не требуется следование конкретному стандарту, обращаются к шаблонам из открытых источников для экономии сил и времени. Вот только можно зря потратить много часов, если безусловно следовать шаблону без понимания теории и практики его применения.
Сам по себе шаблон не гарантирует качественный анализ. Лучше всего работают шаблоны, которые вы сами придумали в своей команде с учетом специфики именно ваших задач. Это похоже на шпаргалку, которую вы составили сами и хорошо понимаете где в ней искать ответ на конкретный вопрос экзамена. Шпаргалка другого студента не будет так хорошо работать в вашем случае, тем более, если она к какому-то другому экзамену.
Например, в одном из шаблонов мне встретился раздел с PESTEL-анализом. Если не понимать, что это за техника и для чего этот раздел, то заполнение потребует времени. Действительно ли будет важен анализ политических, социальных, экономических, экологических факторов в проекте по разработке нового отчета для вашего руководителя? Если формально заполнять разделы, то шаблон может превратиться в пожирателя времени
Шаблон полезен, когда у аналитика есть понимание, что он в нем ищет. Если на новом месте работы обнаружатся шаблоны документов – будет проще ориентироваться в ожиданиях от вашей работы. Когда есть простор в выборе структуры документа – шаблоны подскажут идеи из опыта разных команд. Если вы придумали шаблон сами – получится чек-лист для вашей работы в текущих задачах, но это не обязательно означает, что он выручит и любого другого аналитика.
Делюсь примерами, которые в последнее время попадали в поле зрения. В этом списке нет ни полноты, ни особой логики. Просто небольшая иллюстрация к теме поста.
📍Формат BRD и FSD (ENG)
📍Как писать требования и документацию к проекту. Полный гайд с шаблоном документации и примерами заполнения
📍Что такое бизнес-требования и как с ними не бороться (в последнем разделе статьи структура документа)
📍Артефакты аналитика: документы и техники
📍Как писать требования к проекту. Шаблон документации
📍Стандарты и шаблоны для ТЗ на разработку ПО (обзор форматов, соответственно разным стандартов, со ссылками на примеры)
#мысливслух #что_почитать #инструменты
👍8🔥1
9 месяцев
На этой неделе нашему уютному каналу исполнилось 9 месяцев, вполне солидный возраст для младенца. И вот что я заметила из "родительского" опыта...
В начале работы над каналом я почему-то наивно думала, что читатели приходят только за образовательным контентом и нужно его раздавать побольше. Понаблюдала за собой и за каналом, сходила на курс по написанию постов и поняла простую вещь. Мы читаем каналы и блоги не столько ради каких-то академических полезностей, а ради опыта конкретного автора. Интересно же какие он читает книги, что применяет для решения задач и как у него это получается. Такие посты у нас здесь собирают больше всего лайков. А подборки и книги – больше всего пересылок, видимо, их удобно "прикопать" в каком-то личном списке. Помните про цундоку?
Формат коротких постов оказался хорошей тренировкой в формулировании мыслей. Количество символов в 4096 (а если с фото, то 1024) обязывает учиться видеть слова и даже целые предложения, которые можно убрать из текста без потери смысла. Я стала справляться с этим заметно быстрее и замечаю как входит в привычку на любой свой текст смотреть с прищуром: "А эти слова тут точно нужны? Суть вопроса я передала?" Думаю, привычка не вредная, буду двигаться в этом направлении. То есть писать. Короткими предложениями.
Не очень сложно научиться коротко формулировать мысли и научиться не запихивать больше одной идеи в один пост, а вот раскрывать что-то про себя в формате даже небольшого канала – сложно. Без этого не получается искренний обмен опытом. Есть о чем подумать, а для начала прикрепила к этому посту фото из недавнего отпуска. Это там у меня было время почитать книги 🌱
За ближайшие пару месяцев больше всего просмотров набрали
📍Аналитик с опытом может быть новичком!
📍Мифы о применении опросов при выявлении требований
📍Нужно ли команде тратить время на ревью требований? (peer-to-peer review)
📍Что здесь есть о выявлении требований?
📍Быстрее, лучше, дешевле. Девять методов реинжиниринга бизнес-процессов
#мысливслух #навигация
На этой неделе нашему уютному каналу исполнилось 9 месяцев, вполне солидный возраст для младенца. И вот что я заметила из "родительского" опыта...
В начале работы над каналом я почему-то наивно думала, что читатели приходят только за образовательным контентом и нужно его раздавать побольше. Понаблюдала за собой и за каналом, сходила на курс по написанию постов и поняла простую вещь. Мы читаем каналы и блоги не столько ради каких-то академических полезностей, а ради опыта конкретного автора. Интересно же какие он читает книги, что применяет для решения задач и как у него это получается. Такие посты у нас здесь собирают больше всего лайков. А подборки и книги – больше всего пересылок, видимо, их удобно "прикопать" в каком-то личном списке. Помните про цундоку?
Формат коротких постов оказался хорошей тренировкой в формулировании мыслей. Количество символов в 4096 (а если с фото, то 1024) обязывает учиться видеть слова и даже целые предложения, которые можно убрать из текста без потери смысла. Я стала справляться с этим заметно быстрее и замечаю как входит в привычку на любой свой текст смотреть с прищуром: "А эти слова тут точно нужны? Суть вопроса я передала?" Думаю, привычка не вредная, буду двигаться в этом направлении. То есть писать. Короткими предложениями.
Не очень сложно научиться коротко формулировать мысли и научиться не запихивать больше одной идеи в один пост, а вот раскрывать что-то про себя в формате даже небольшого канала – сложно. Без этого не получается искренний обмен опытом. Есть о чем подумать, а для начала прикрепила к этому посту фото из недавнего отпуска. Это там у меня было время почитать книги 🌱
За ближайшие пару месяцев больше всего просмотров набрали
📍Аналитик с опытом может быть новичком!
📍Мифы о применении опросов при выявлении требований
📍Нужно ли команде тратить время на ревью требований? (peer-to-peer review)
📍Что здесь есть о выявлении требований?
📍Быстрее, лучше, дешевле. Девять методов реинжиниринга бизнес-процессов
#мысливслух #навигация
👍9❤4👏2🔥1🤡1
Гантт, Адамецкий и PlantUml
Поиск Яндекса по фразе "диаграмма Гантта" на первой странице выдает рекламу 4-5 инструментов, чтобы ее легко и быстро построить и столько же статей с названием "Топ-10 инструментов ...". Недавно вспомнила эту диаграмму в одной из задач и рисовала ее в PlantUml. Стало интересно насколько жизнеспособна на сегодняшний день штука, которая связана в наших головах с управлением сроками, жестким планированием и вообще бюрократией
Впервые чарт с соотношением задач к затраченному времени стали применять в 1896 году, это была гармонограмма Адамецкого. Польский ученый пришел к своей концепции изучая производительность труда в прокатном производстве и доказывая, что она невысока не из-за лени рабочих, а из-за несогласованности между операциями и простоев. Концепция называется концепцией гармонизации, так как состоит в совмещении (гармонии) графиков работы оборудования и людей. Адамецкий выделил контроль как функцию управления, определил его назначение, этапы и механизмы и предупредил, что «контроль является средством, а не целью…» (источник Концепция управления Кароля Адамецки//Менеджмент в России и за рубежом, 2011 №2)
Привычные нам горизонтальные "колбаски" были сформированы Генри Ганттом чуть позже, в 1910. Можно найти немало статей, где сравниваются техники Адамецкого и Гантта, например вот эта Первый человек менеджмента:история Кароля Адамецкого, здесь же приведен внешний вид гармонограммы и прибора для ее составления
Первая картинка к этому посту из статьи Гантта Organizing for work, 1919 и показывает стоимость бездействия оборудования на предприятии, результат неэффективного управления. Интересно, что диаграмма применялась в этой работе, чтобы визуально показать потери и их причины. Большая разница с теперешними попытками зафиксировать этапность и неукоснительно контролировать исполнение
Сама по себе диаграмма не может напрямую быть единственным и безотказным инструментом управления. Однажды зафиксированная картина не заставит реальность полностью ей соответствовать и не заставит сдвинуть задачу с места. Диаграмма задумывалась для визуальной иллюстрации текущего состояния дел на производстве, для планирования работ и оценки масштабов. "Диаграммы Гантта быстро устаревали, так как не учитывали нестабильность в работе оборудования, производительности труда, сбои в поставках ресурсов и пр. ...Составление диаграмм Гантта постоянно усложняется в связи с увеличением числа операций" (из статьи Marsh Ed.R. The garmonogram of Karol Adameicki, 1975 год)
У многих моих коллег диаграмма Гантта вызывает аллергию как один из атрибутов Waterfall, а еще хуже, как символ тотального контроля со стороны менеджеров. Я и сама, когда решила использовать этот инструмент, решила учесть риск, что это сработает против меня и превратится в инструмент манипуляции сроками. Тем не менее не вижу ничего плохо в том, чтобы спланировать для себя краткосрочную задачу и двигать сроки, если необходимо. При этом не нужно наделять этот инструмент магией, которой в нем на самом деле нет
На второй картинке – результат моих экспериментов в PlantUml. Стало скучно просто рисовать прямоугольники или проставлять цифры в MS Project, решила попробовать такой подход. Если делать в инструменте, где вы в соседнем окошке видите результат изменения кода, например в VS Code с плагином PlantUml, то получается очень удобно. Выводишь календарь с нужным шагом (год, квартал, неделя, день), проставляешь длительность и даты, исправляешь, если попал на выходной. В моем случае все просто, так как это задача одного исполнителя с малым количеством этапов, если зависимостей и ресурсов много, то будет сложнее
📌Статья об иллюзии контроля (EN)
📌Статья про диаграмму, могут быть полезны ссылки на онлайн инструменты для построения
📌Давняя, но зато короткая и простая инструкция для VS Code, если еще не пользуетесь
📌Спецификация PlantUml для диаграммы Гантта, там в первой строчке написано про инструмент управления проектами, но нас же этим уже не обманешь?
📌Файлик с моим примером PlantUml на Яндекс.Диске
#что_почитать #инструменты #кейс
Поиск Яндекса по фразе "диаграмма Гантта" на первой странице выдает рекламу 4-5 инструментов, чтобы ее легко и быстро построить и столько же статей с названием "Топ-10 инструментов ...". Недавно вспомнила эту диаграмму в одной из задач и рисовала ее в PlantUml. Стало интересно насколько жизнеспособна на сегодняшний день штука, которая связана в наших головах с управлением сроками, жестким планированием и вообще бюрократией
Впервые чарт с соотношением задач к затраченному времени стали применять в 1896 году, это была гармонограмма Адамецкого. Польский ученый пришел к своей концепции изучая производительность труда в прокатном производстве и доказывая, что она невысока не из-за лени рабочих, а из-за несогласованности между операциями и простоев. Концепция называется концепцией гармонизации, так как состоит в совмещении (гармонии) графиков работы оборудования и людей. Адамецкий выделил контроль как функцию управления, определил его назначение, этапы и механизмы и предупредил, что «контроль является средством, а не целью…» (источник Концепция управления Кароля Адамецки//Менеджмент в России и за рубежом, 2011 №2)
Привычные нам горизонтальные "колбаски" были сформированы Генри Ганттом чуть позже, в 1910. Можно найти немало статей, где сравниваются техники Адамецкого и Гантта, например вот эта Первый человек менеджмента:история Кароля Адамецкого, здесь же приведен внешний вид гармонограммы и прибора для ее составления
Первая картинка к этому посту из статьи Гантта Organizing for work, 1919 и показывает стоимость бездействия оборудования на предприятии, результат неэффективного управления. Интересно, что диаграмма применялась в этой работе, чтобы визуально показать потери и их причины. Большая разница с теперешними попытками зафиксировать этапность и неукоснительно контролировать исполнение
Сама по себе диаграмма не может напрямую быть единственным и безотказным инструментом управления. Однажды зафиксированная картина не заставит реальность полностью ей соответствовать и не заставит сдвинуть задачу с места. Диаграмма задумывалась для визуальной иллюстрации текущего состояния дел на производстве, для планирования работ и оценки масштабов. "Диаграммы Гантта быстро устаревали, так как не учитывали нестабильность в работе оборудования, производительности труда, сбои в поставках ресурсов и пр. ...Составление диаграмм Гантта постоянно усложняется в связи с увеличением числа операций" (из статьи Marsh Ed.R. The garmonogram of Karol Adameicki, 1975 год)
У многих моих коллег диаграмма Гантта вызывает аллергию как один из атрибутов Waterfall, а еще хуже, как символ тотального контроля со стороны менеджеров. Я и сама, когда решила использовать этот инструмент, решила учесть риск, что это сработает против меня и превратится в инструмент манипуляции сроками. Тем не менее не вижу ничего плохо в том, чтобы спланировать для себя краткосрочную задачу и двигать сроки, если необходимо. При этом не нужно наделять этот инструмент магией, которой в нем на самом деле нет
На второй картинке – результат моих экспериментов в PlantUml. Стало скучно просто рисовать прямоугольники или проставлять цифры в MS Project, решила попробовать такой подход. Если делать в инструменте, где вы в соседнем окошке видите результат изменения кода, например в VS Code с плагином PlantUml, то получается очень удобно. Выводишь календарь с нужным шагом (год, квартал, неделя, день), проставляешь длительность и даты, исправляешь, если попал на выходной. В моем случае все просто, так как это задача одного исполнителя с малым количеством этапов, если зависимостей и ресурсов много, то будет сложнее
📌Статья об иллюзии контроля (EN)
📌Статья про диаграмму, могут быть полезны ссылки на онлайн инструменты для построения
📌Давняя, но зато короткая и простая инструкция для VS Code, если еще не пользуетесь
📌Спецификация PlantUml для диаграммы Гантта, там в первой строчке написано про инструмент управления проектами, но нас же этим уже не обманешь?
📌Файлик с моим примером PlantUml на Яндекс.Диске
#что_почитать #инструменты #кейс
👍3🔥2