Распаковка рюкзака с конференции 1. Стикеры, книги, впечатления
Иннополис – один из наукоградов. Минут 40 на машине от центра Казани. В 2012 году его начали строить буквально в чистом поле. На официальном сайте города пишут, что теперь там 7800 иннополисян, дословно. Часто слышу об этом месте в контексте корпоративных программ, но сама увидела впервые.
Вышла из такси в 8:40 в субботу и удивилась атмосфере. Огромные здания кампуса Университета Иннополиса, Технопарк, а рядом несколько жилых кварталов. Буквально через дорогу от кампуса детские и взрослые велосипеды ночуют у таунхаусов, а любители утренних пробежек бодро преодолевают местные дорожки... Ну и еще такие же как я ходят с бейджиками и что-то обсуждают. Интересная архитектура, бегают беспилотные такси. Я себя чувствовала в городе будущего, пока не начала искать розетки. Но об этом позже.
Попала только на второй день конфы, но сразу оценила тренд – очереди за кофе в перерывах, своего рода нетворинг. Что касается стикеров, то этот вид мерче-валюты стал встречаться на конфах все реже и Merge не исключение. Хотя, может, все собрали со стендов уже в первый день?
Был мой любимый вид развлечений – книжная ярмарка. Каждый раз обещаю себе не нагружаться, но это что-то из серии "ну я еще немного, а в следующий раз не буду". Добавила в рюкзак пару килограммов полезностей.
К середине для словила приступ паники "А где тут розетки?" на регистрации честно сказали "а тут точек зарядки нет". Хорошо, что нашлись переговорки с розетками. В общем, отправляясь в будущее, не забывайте power bank.
Насчитала 11 стримов, аудитории распределены на трех этажах огромного здания университета. К середине дня устала постоянно оптимизировать маршруты между докладами, чтобы поменьше бегать по зданию. Зато спустя 20+ лет после учебы посидела в учебной аудитории с ярусами столов. Оказалось, что со временем становится важным еще и удобство стульев 🤷♀️
В целом открыла для себя три вещи: dogfooding, коллективное лидерство и боль в спине 😊
#конференции
Иннополис – один из наукоградов. Минут 40 на машине от центра Казани. В 2012 году его начали строить буквально в чистом поле. На официальном сайте города пишут, что теперь там 7800 иннополисян, дословно. Часто слышу об этом месте в контексте корпоративных программ, но сама увидела впервые.
Вышла из такси в 8:40 в субботу и удивилась атмосфере. Огромные здания кампуса Университета Иннополиса, Технопарк, а рядом несколько жилых кварталов. Буквально через дорогу от кампуса детские и взрослые велосипеды ночуют у таунхаусов, а любители утренних пробежек бодро преодолевают местные дорожки... Ну и еще такие же как я ходят с бейджиками и что-то обсуждают. Интересная архитектура, бегают беспилотные такси. Я себя чувствовала в городе будущего, пока не начала искать розетки. Но об этом позже.
Попала только на второй день конфы, но сразу оценила тренд – очереди за кофе в перерывах, своего рода нетворинг. Что касается стикеров, то этот вид мерче-валюты стал встречаться на конфах все реже и Merge не исключение. Хотя, может, все собрали со стендов уже в первый день?
Был мой любимый вид развлечений – книжная ярмарка. Каждый раз обещаю себе не нагружаться, но это что-то из серии "ну я еще немного, а в следующий раз не буду". Добавила в рюкзак пару килограммов полезностей.
К середине для словила приступ паники "А где тут розетки?" на регистрации честно сказали "а тут точек зарядки нет". Хорошо, что нашлись переговорки с розетками. В общем, отправляясь в будущее, не забывайте power bank.
Насчитала 11 стримов, аудитории распределены на трех этажах огромного здания университета. К середине дня устала постоянно оптимизировать маршруты между докладами, чтобы поменьше бегать по зданию. Зато спустя 20+ лет после учебы посидела в учебной аудитории с ярусами столов. Оказалось, что со временем становится важным еще и удобство стульев 🤷♀️
В целом открыла для себя три вещи: dogfooding, коллективное лидерство и боль в спине 😊
#конференции
Распаковка рюкзака с конференции 2. Коллективное лидерство
В рюкзаке нашлись еще заметки о докладах. Сейчас про доклад под названием "Коллективное лидерство: как сделать ответственность желанной, а ценность постоянной" (программа тут)
Это был разговор о подходах к управлению задачами. Тот, о котором шла речь, встречается еще под названием "фича-лидер". Спикер рассказал как это работает в его команде.
Есть декомпозиция на стори и любой участник команды может вызваться любую такую историю лидировать от проработки до внедрения. Примеров на слайдах не запомнила, а было бы интересно, потому что для меня стори – это что-то не обязательно большое и требующее отдельного лидерства.
Обсудили саму природу лидерства. Имелось в виду не формально назначенное лидерство, а именно сформированное в команде, когда она признает в ком-то вожака. От такого лидера ожидается:
📍Наставничество;
📍Поддержание атмосферы;
📍Медиация, как функция третейского судьи в случае конфликтов;
📍Объективность;
📍Этический ориентир, бывает, что кто-то задает тон коммуникаций и производительности в команде. "Если лидер не спешит, то почему всем остальным нужно" и наоборот, "а у него отлично получается и я так хочу".
Лидер для стори должен вызваться сам, если кого-то назначить, то это уже не про желанную ответственность. Были случаи, когда на одну стори вызвалось два лидера и тогда ее еще раздробили, чтобы у каждого был шанс проявить себя.
Для реализации собирается временная команда, чтобы запилить стори под руководством лидера. Получается, что можно попробовать реализовать амбицию "я бы это сделал лучше", потренировать софт-скилл и потестировать свои лидерские качества.
В докладе был рассказ еще и внешней мотивации в виде премии от руководителя за успехи в роли лидера. Сама по себе внешняя мотивация, на мой взгляд, штука спорная и может обесценить всю затею, но мне понравился подход к оценке. Решения о премировании принимаются на основании опроса всех участников процесса, сами по себе вопросы нейтральные и оценивают скорее Soft skill и мнения самих участников. Например, человек оценивает как ему удалось продвинуться в навыках или насколько он готов снова работать в том же составе. В итоге на основании ответов подсчитывается балл для лидера и получается целая турнирная таблица лидеров на основании обратной связи. Такая таблица открыта всем в команде, а сами детальные ответы, конечно, не раскрываются.
Как вам такой подход? Мне показался интересным, я бы к этому добавила еще совет почитать книгу Дейва Пинка "Драйв" в продолжение темы мотивации.
Где-то на дне рюкзака осталось еще пара заметок, скоро вернусь со следующей распаковкой 🎒
#конференции #инструменты #agile
В рюкзаке нашлись еще заметки о докладах. Сейчас про доклад под названием "Коллективное лидерство: как сделать ответственность желанной, а ценность постоянной" (программа тут)
Это был разговор о подходах к управлению задачами. Тот, о котором шла речь, встречается еще под названием "фича-лидер". Спикер рассказал как это работает в его команде.
Есть декомпозиция на стори и любой участник команды может вызваться любую такую историю лидировать от проработки до внедрения. Примеров на слайдах не запомнила, а было бы интересно, потому что для меня стори – это что-то не обязательно большое и требующее отдельного лидерства.
Обсудили саму природу лидерства. Имелось в виду не формально назначенное лидерство, а именно сформированное в команде, когда она признает в ком-то вожака. От такого лидера ожидается:
📍Наставничество;
📍Поддержание атмосферы;
📍Медиация, как функция третейского судьи в случае конфликтов;
📍Объективность;
📍Этический ориентир, бывает, что кто-то задает тон коммуникаций и производительности в команде. "Если лидер не спешит, то почему всем остальным нужно" и наоборот, "а у него отлично получается и я так хочу".
Лидер для стори должен вызваться сам, если кого-то назначить, то это уже не про желанную ответственность. Были случаи, когда на одну стори вызвалось два лидера и тогда ее еще раздробили, чтобы у каждого был шанс проявить себя.
Для реализации собирается временная команда, чтобы запилить стори под руководством лидера. Получается, что можно попробовать реализовать амбицию "я бы это сделал лучше", потренировать софт-скилл и потестировать свои лидерские качества.
В докладе был рассказ еще и внешней мотивации в виде премии от руководителя за успехи в роли лидера. Сама по себе внешняя мотивация, на мой взгляд, штука спорная и может обесценить всю затею, но мне понравился подход к оценке. Решения о премировании принимаются на основании опроса всех участников процесса, сами по себе вопросы нейтральные и оценивают скорее Soft skill и мнения самих участников. Например, человек оценивает как ему удалось продвинуться в навыках или насколько он готов снова работать в том же составе. В итоге на основании ответов подсчитывается балл для лидера и получается целая турнирная таблица лидеров на основании обратной связи. Такая таблица открыта всем в команде, а сами детальные ответы, конечно, не раскрываются.
Как вам такой подход? Мне показался интересным, я бы к этому добавила еще совет почитать книгу Дейва Пинка "Драйв" в продолжение темы мотивации.
Где-то на дне рюкзака осталось еще пара заметок, скоро вернусь со следующей распаковкой 🎒
#конференции #инструменты #agile
Распаковка рюкзака с конференции 3. Закон Миллера, Монте-Карло и dogfooding
Еще порция заметок с недавней Merge.
Большинство аналитиков неправильно используют требования и их классификацию. А ты? Рассказ о подходах к классификации требований и ее целях. Доклад в программе.
По закону Миллера кратковременная память человека оперирует количеством элементов от 5 до 9. Как только вы пытаетесь впихнуть в границы анализа больше, получается каша, которую сложно обработать. Мозг пытается сгруппировать увиденное и свести к посильному количеству знакомых объектов, так за деталями теряются цели и "дорисовываются" объекты.
Принципы ООП тоже работают для требований, помогают сократить количество объектов. Абстрагирование — выделение только значимых элементов. Инкапсуляция - скрывание деталей системы и фокус на её взаимодействии с внешним миром.
Классификация помогает выделить уровни информации и на каждом оперировать только теми объектами, что для него значимы. Плохо работает "верхнеуровневое БТ", где вперемешку указаны цели доработки, требования к решению, куски архитектуры и json-схемы.
📌Классификация требований не для обозначения уровней детализации, а для снижения сложности
📌Требования задают контракт: зоны ответственности и компетенций
📌Формулировать системные требования нужно так, чтобы оставить проработку деталей реализации другим компетенциям. За деталями теряется целое и возникают лишние ограничения
📌Не следует подменять работу с требованиями полным проектирование системы.
Тут вспомнила доклад Юрия Куприянова на Flow, что требования плотно связаны с решением, что описание требований свелось к придумыванию решения вместе с заказчиком. Есть и такое мнение.
От покера до футболок, выбор метода оценки ИТ задач. Доклад в программе. Советы по методам оценки задач. Метод важно выбрать соответственно ситуации. Если 10 специалистов час сидят на встрече по планированию задач, это суммарно10 часов рабочего времени потрачено. У каждого метода свои условия применения и своя чувствительность к неопределенности, зависимостям, сложности. Речь шла о таких методах:
📌Scrum покер, когда используются карты с цифрой оценки и участники одновременно открывают свои карты. Подходит для небольших команд и хорош вовлечением участников, требует опыта и времени на обсуждение.
📌Метод футболок, когда оценка дается буквой S,M,L. Подходит для небольших команд, простой и понятный, но не точный.
📌Три амиго, когда эксперты разных областей (DEV,BA/SA,QA) обсуждают задачу. Хорош для задач с высоким уровнем неопределенности, требует времени ключевых экспертов.
📌PERT, когда оцениваются сценарии оптимистичный (O), наиболее вероятный (R), пессимистичный (P). Итоговую оценку подсчитывают как (O+4*R+P)\6. Учитывает неопределенность, подходит для сложных и долгосрочных проектов, но сложен и зависит от точности оценок.
📌Монте-Карло, статистический метод на основе данных о сроках выполнения задач из таск-трекера. Для начала нужны данные не менее, чем за 7 недель работы команды. Метод зависит от качества статистической модели, но хорошо визуализирует результаты расчетов и подходит для сложных проектов. Несколько слов о методе привозила с Dump в феврале тут.
Пока ждем записей докладов в общем доступе можно посмотреть в этом канале пост о техниках оценки задач.
Dogfooding as a Service - как "сломать" продукт так, чтобы команда тебе была благодарна. Доклад в программе. Dogfooding – это использование сотрудниками компании продуктов этой же компании для анализа достоинств и недостатков. Название пришло от производителей собачьего корма, среди которых кто-то утверждал что готов съесть свой прекрасный продукт сам, а кто-то съел банку корма на собрании акционеров (подробнее в статье)
Доклад о том, как организован процесс. Смутили две вещи. 1) Процесс на добровольных началах и организаторы, и участники работают на добровольных началах вне основных задач. 2) По наблюдениям автора не более 50% собранных замечаний ложатся в бэклоги команд разработки, а остальное – дубли, уже известные идеи и пр.
На этом все распаковала. Всем прекрасных майских выходных 🔅
#конференции
Еще порция заметок с недавней Merge.
Большинство аналитиков неправильно используют требования и их классификацию. А ты? Рассказ о подходах к классификации требований и ее целях. Доклад в программе.
По закону Миллера кратковременная память человека оперирует количеством элементов от 5 до 9. Как только вы пытаетесь впихнуть в границы анализа больше, получается каша, которую сложно обработать. Мозг пытается сгруппировать увиденное и свести к посильному количеству знакомых объектов, так за деталями теряются цели и "дорисовываются" объекты.
Принципы ООП тоже работают для требований, помогают сократить количество объектов. Абстрагирование — выделение только значимых элементов. Инкапсуляция - скрывание деталей системы и фокус на её взаимодействии с внешним миром.
Классификация помогает выделить уровни информации и на каждом оперировать только теми объектами, что для него значимы. Плохо работает "верхнеуровневое БТ", где вперемешку указаны цели доработки, требования к решению, куски архитектуры и json-схемы.
📌Классификация требований не для обозначения уровней детализации, а для снижения сложности
📌Требования задают контракт: зоны ответственности и компетенций
📌Формулировать системные требования нужно так, чтобы оставить проработку деталей реализации другим компетенциям. За деталями теряется целое и возникают лишние ограничения
📌Не следует подменять работу с требованиями полным проектирование системы.
Тут вспомнила доклад Юрия Куприянова на Flow, что требования плотно связаны с решением, что описание требований свелось к придумыванию решения вместе с заказчиком. Есть и такое мнение.
От покера до футболок, выбор метода оценки ИТ задач. Доклад в программе. Советы по методам оценки задач. Метод важно выбрать соответственно ситуации. Если 10 специалистов час сидят на встрече по планированию задач, это суммарно10 часов рабочего времени потрачено. У каждого метода свои условия применения и своя чувствительность к неопределенности, зависимостям, сложности. Речь шла о таких методах:
📌Scrum покер, когда используются карты с цифрой оценки и участники одновременно открывают свои карты. Подходит для небольших команд и хорош вовлечением участников, требует опыта и времени на обсуждение.
📌Метод футболок, когда оценка дается буквой S,M,L. Подходит для небольших команд, простой и понятный, но не точный.
📌Три амиго, когда эксперты разных областей (DEV,BA/SA,QA) обсуждают задачу. Хорош для задач с высоким уровнем неопределенности, требует времени ключевых экспертов.
📌PERT, когда оцениваются сценарии оптимистичный (O), наиболее вероятный (R), пессимистичный (P). Итоговую оценку подсчитывают как (O+4*R+P)\6. Учитывает неопределенность, подходит для сложных и долгосрочных проектов, но сложен и зависит от точности оценок.
📌Монте-Карло, статистический метод на основе данных о сроках выполнения задач из таск-трекера. Для начала нужны данные не менее, чем за 7 недель работы команды. Метод зависит от качества статистической модели, но хорошо визуализирует результаты расчетов и подходит для сложных проектов. Несколько слов о методе привозила с Dump в феврале тут.
Пока ждем записей докладов в общем доступе можно посмотреть в этом канале пост о техниках оценки задач.
Dogfooding as a Service - как "сломать" продукт так, чтобы команда тебе была благодарна. Доклад в программе. Dogfooding – это использование сотрудниками компании продуктов этой же компании для анализа достоинств и недостатков. Название пришло от производителей собачьего корма, среди которых кто-то утверждал что готов съесть свой прекрасный продукт сам, а кто-то съел банку корма на собрании акционеров (подробнее в статье)
Доклад о том, как организован процесс. Смутили две вещи. 1) Процесс на добровольных началах и организаторы, и участники работают на добровольных началах вне основных задач. 2) По наблюдениям автора не более 50% собранных замечаний ложатся в бэклоги команд разработки, а остальное – дубли, уже известные идеи и пр.
На этом все распаковала. Всем прекрасных майских выходных 🔅
#конференции
Прочитала у одного прекрасного автора, что отдых нужно планировать как задачу и не забывать формулировать цели, критерии приемки, сроки. Мои цели на отдых – пару дней гулять в Хвалынском национальном парке и быть подальше от ноутбука, а потом еще пару дней со свежей головой читать, разбирать материалы и сочинять. Так и получились фото волжских просторов и новая подборка👇
BAST или мы так и не знаем чем занимается аналитик
Две недели назад коллега прислал файл с The Business Analysis Standard от IIBA. В некоторых статьях этот документ называют BAST. Добралась посмотреть. Интересно же, что нового придумали в IIBA, кроме BABOK, так и оставшегося в версии 3.0 от 2015 года?
BA Standard в первой версии появился под названием The Global Business Analysis Core Standard, сейчас доступна уже вторая его версия. Показательно, что ссылка на скачивание содержит название The-Standard, если дословно переводить, то можно сказать "единственный и уникальный". Сам материал на 58 страницах стандарта я бы не назвала принципиально новым. В предисловии так и сказано, что все 6 сфер знания и 30 аналитических задач остались неизменными.
В одном из экспертных чатов эту книгу назвали "выжимка из BABOK" и действительно выглядит именно так.
В BA Standard те же ключевые принципы бизнес-анализа, изложенных в BABOK Guide. Из нового: дополнены разделы о мышлении бизнес-аналитика (business analysis mindset), сделан акцент на зоны ответственности аналитика в рамках разных подходов к организации задач (approaches), они бывают каскадные (predictive), гибкие (agile) и гибридные.
Интереснее наблюдать за изменением общего подхода IIBA. Похоже, что подход меняется с учетом растущего количества очень разных аналитиков в очень разном контексте и делается попытка дать общий ответ на вопрос "чем же занимается аналитик?" В начале нулевых эта роль была новой и BABOK среди прочих стандартов помогал в ней разобраться, с тех пор аналитики разбрелись по разным направлениям и вопрос "чем же занимается аналитик?" очень актуален снова.
Новый документ ориентирован на более широкую аудиторию, включая руководителей организаций и специалистов разных ролей. Зачем он им? Чтобы объяснить роль аналитика и быть источником терминологии и стандартизированного словаря в области бизнес-анализа как его понимает IIBA😉 Предполагается BA Standard обновлять каждые полтора-два года. Это не просто краткая версия BABOK Guide, это ось для других публикаций IIBA и содержит на них ссылки:
📍BABOK Guide,
📍Agile Extension,
📍Business Data Analysis Guide,
📍Product Ownership Analysis Guide.
В отличие от прочих изданий BA Standard можно скачать свободно по ссылке, в обмен на ваши персональные данные 😊
Поиском по Хабру и по ТГ нашлось не слишком много статей. Поделюсь парой обзоров:
📚Сопоставление «The Business Analysis Standard» IIBA с профстандартом бизнес-аналитика РФ
📚(EN) Статья в блоге IIBA The BAST: The New Gravitational Centre of Business Analysis
#что_почитать #книжки
Две недели назад коллега прислал файл с The Business Analysis Standard от IIBA. В некоторых статьях этот документ называют BAST. Добралась посмотреть. Интересно же, что нового придумали в IIBA, кроме BABOK, так и оставшегося в версии 3.0 от 2015 года?
BA Standard в первой версии появился под названием The Global Business Analysis Core Standard, сейчас доступна уже вторая его версия. Показательно, что ссылка на скачивание содержит название The-Standard, если дословно переводить, то можно сказать "единственный и уникальный". Сам материал на 58 страницах стандарта я бы не назвала принципиально новым. В предисловии так и сказано, что все 6 сфер знания и 30 аналитических задач остались неизменными.
В одном из экспертных чатов эту книгу назвали "выжимка из BABOK" и действительно выглядит именно так.
В BA Standard те же ключевые принципы бизнес-анализа, изложенных в BABOK Guide. Из нового: дополнены разделы о мышлении бизнес-аналитика (business analysis mindset), сделан акцент на зоны ответственности аналитика в рамках разных подходов к организации задач (approaches), они бывают каскадные (predictive), гибкие (agile) и гибридные.
Интереснее наблюдать за изменением общего подхода IIBA. Похоже, что подход меняется с учетом растущего количества очень разных аналитиков в очень разном контексте и делается попытка дать общий ответ на вопрос "чем же занимается аналитик?" В начале нулевых эта роль была новой и BABOK среди прочих стандартов помогал в ней разобраться, с тех пор аналитики разбрелись по разным направлениям и вопрос "чем же занимается аналитик?" очень актуален снова.
Новый документ ориентирован на более широкую аудиторию, включая руководителей организаций и специалистов разных ролей. Зачем он им? Чтобы объяснить роль аналитика и быть источником терминологии и стандартизированного словаря в области бизнес-анализа как его понимает IIBA😉 Предполагается BA Standard обновлять каждые полтора-два года. Это не просто краткая версия BABOK Guide, это ось для других публикаций IIBA и содержит на них ссылки:
📍BABOK Guide,
📍Agile Extension,
📍Business Data Analysis Guide,
📍Product Ownership Analysis Guide.
В отличие от прочих изданий BA Standard можно скачать свободно по ссылке, в обмен на ваши персональные данные 😊
Поиском по Хабру и по ТГ нашлось не слишком много статей. Поделюсь парой обзоров:
📚Сопоставление «The Business Analysis Standard» IIBA с профстандартом бизнес-аналитика РФ
📚(EN) Статья в блоге IIBA The BAST: The New Gravitational Centre of Business Analysis
#что_почитать #книжки
Лидерство, чтобы что?
Как-то на конференции выписывала тезисы доклада о фича-лидерстве. Перечитала. Стало интересно подумать о природе такого подхода и контексте применения.
Feature Lead – это ответственный за разработку конкретной функциональности (фичи) в проекте, ответственность временная. На практике обычно помимо своей основной работы разработчик, аналитик или другой эксперт занимается координацией полного цикла разработки по своей фиче, включая планирование сроков, все коммуникации, контроль качества. Такой подход не везде назовут именно таким именем, но применяется он сравнительно часто.
Беспроигрышный вариант для сотрудника, когда у него есть желание разобраться как принимаются решения, участвовать в них и оценивать результат своих решений. Совсем хорошо, если у него есть желание перейти в менеджмент. Получится сделать фичу "под ключ" – отлично, кроме того можно с чистой совестью показать результат в резюме. А не получится – риск не очень велик, продолжается экспертная работа, а с ответственностью и лидерством можно через какое-то время попробовать снова, сделав выводы из неудач. Для аналитика это шаг в бОльшую ответственность, если делать этот шаг добровольно, то может быть даже интересно.
В публикациях встречаю точку зрения сотрудника, здесь понятно. Только фичи не реализуются в вакууме. Как подход встроен в общий процесс разработки?
📌Попробовала поспрашивать DeepSeek о роли фича-лида, он сбивается на понятие agile feature team и в этом есть что-то рациональное. Если есть лидер фичи, должна быть команда, иначе откуда взяться разработке? Можно просто ставить задачи в бэклог, но тогда у команд получается расфокус – приходится и поставленное владельцем продукта поддерживать, и подхватывать что-то сбоку "потому что очень попросили", и про собственный тех.долг не забыть.
📌Если имеется несколько фич и их лидами, то нужна координация по изменениям продуктовой стратегии и инфрастуктурным изменениям, иначе часть фичей может не дойти дойти до внедрения. Или дойти, но не внедриться.
📌Не выглядит ли подход как замена проектного менеджмента руками из смежных областей?
Пока не разобралась в чем проблема с фичами. Если недостаточно синхронизации в решении вопроса, полезно ли добавить еще участников синхронизации как бы те ни назывались? или фич слишком много, команды вместе с продактами уже запутались и нужен еще кто-то? Не вижу очевидного ответа на вопрос "чтобы что?"😎
📚
▫️Аналитик фича - лид - точно ли спасатель! доклад с Лаф прошлого года
▫️Пост о фича-лидерах в канале Юрия Куприянова
▫️Просветлённый выживший: кто такой фичекрайний и зачем это всё разработчику? Статья в блоге 2ГИС, где автор описал свои впечатления от роли ответственного за фичу. В комментариях к статье осудили сомнительное словообразование "фичекрайний", а ведь и правда есть в этом что-то противоречащее определению "мотивированная добровольная ответственность".
#что_почитать #мысливслух
Как-то на конференции выписывала тезисы доклада о фича-лидерстве. Перечитала. Стало интересно подумать о природе такого подхода и контексте применения.
Feature Lead – это ответственный за разработку конкретной функциональности (фичи) в проекте, ответственность временная. На практике обычно помимо своей основной работы разработчик, аналитик или другой эксперт занимается координацией полного цикла разработки по своей фиче, включая планирование сроков, все коммуникации, контроль качества. Такой подход не везде назовут именно таким именем, но применяется он сравнительно часто.
Беспроигрышный вариант для сотрудника, когда у него есть желание разобраться как принимаются решения, участвовать в них и оценивать результат своих решений. Совсем хорошо, если у него есть желание перейти в менеджмент. Получится сделать фичу "под ключ" – отлично, кроме того можно с чистой совестью показать результат в резюме. А не получится – риск не очень велик, продолжается экспертная работа, а с ответственностью и лидерством можно через какое-то время попробовать снова, сделав выводы из неудач. Для аналитика это шаг в бОльшую ответственность, если делать этот шаг добровольно, то может быть даже интересно.
В публикациях встречаю точку зрения сотрудника, здесь понятно. Только фичи не реализуются в вакууме. Как подход встроен в общий процесс разработки?
📌Попробовала поспрашивать DeepSeek о роли фича-лида, он сбивается на понятие agile feature team и в этом есть что-то рациональное. Если есть лидер фичи, должна быть команда, иначе откуда взяться разработке? Можно просто ставить задачи в бэклог, но тогда у команд получается расфокус – приходится и поставленное владельцем продукта поддерживать, и подхватывать что-то сбоку "потому что очень попросили", и про собственный тех.долг не забыть.
📌Если имеется несколько фич и их лидами, то нужна координация по изменениям продуктовой стратегии и инфрастуктурным изменениям, иначе часть фичей может не дойти дойти до внедрения. Или дойти, но не внедриться.
📌Не выглядит ли подход как замена проектного менеджмента руками из смежных областей?
Пока не разобралась в чем проблема с фичами. Если недостаточно синхронизации в решении вопроса, полезно ли добавить еще участников синхронизации как бы те ни назывались? или фич слишком много, команды вместе с продактами уже запутались и нужен еще кто-то? Не вижу очевидного ответа на вопрос "чтобы что?"
📚
▫️Аналитик фича - лид - точно ли спасатель! доклад с Лаф прошлого года
▫️Пост о фича-лидерах в канале Юрия Куприянова
▫️Просветлённый выживший: кто такой фичекрайний и зачем это всё разработчику? Статья в блоге 2ГИС, где автор описал свои впечатления от роли ответственного за фичу. В комментариях к статье осудили сомнительное словообразование "фичекрайний", а ведь и правда есть в этом что-то противоречащее определению "мотивированная добровольная ответственность".
#что_почитать #мысливслух
Please open Telegram to view this post
VIEW IN TELEGRAM
Из БА в СА это всегда рост?
Дождь над Финским заливом, отпуск и новое в папке каналов "Про анализ". Встретила несколько постов о ролях аналитиков с комментариями в духе "Я вырос из БА до СА/ разработчика" – и задумалась. Почему принято называть ростом переход в другую роль, хотя это по сути смена навыков и контекста? Почему мы пытаемся оценивать карьеру какими-то ступенями, хотя это забег длиной в 40+ лет со сложными поворотами?
Знаете детский стих "Мама – летчик? Что ж такого!" с финалом "Дело было вечером, спорить было нечего." Так и слово "рост" в этом контексте, если разобраться, даже не предмет спора.
Когда я в середине девяностых планировала поступать на мех-мат, друзья и знакомые крутили пальцем у виска. Заводы закрывались, инженерам жилось непросто. Самые амбициозные шли поступать на экономистов или юристов. В моём вузе на математические специальности, скорее всего, был недобор. Родители убедили, что математика – это знание, из которого можно развиваться куда угодно. Не знаю, просчитывали ли они на 20 лет вперёд, но оказались правы: красный диплом по прикладной математике открыл мне многие возможности.
Первой строчкой в трудовой было "инженер-программист". Звучит солидно, но на деле оказалось пыткой для моего темперамента. Он с трудом выдерживал написание кода с 8:00 до 17:00 при минимуме общения. Терпение и дисциплина помогают решать задачи и временами меня хвалили, но запасы этих качеств за неполных три года истощились.
Примерно тогда же, когда закончилось терпение, в мой город пришла заказная разработка, а с ней - новые роли в производстве ПО. Так я оказалась в тестировании. Через пару лет я уже в роли QA лида и снова темперамент протестует против составления баг-репортов и тест-кейсов. Распределять задачи команде неплохо, но где же исследования и драйв неопределенности?😎
На мое счастье в проектах появились бизнес аналитики, которые много путешествовали по предприятиям заказчиков и на международных проектах постоянно практиковали английский. Здесь нам с моим темпераментом стало хорошо. Мы с темпераментом вечно с кем-то общались, мчались на вокзал или в аэропорт в любую погоду и даже 8го марта. Мои английский и немецкий из хобби превратились в инструмент для расшифровки кривых постановок от немецких заказчиков. Здесь я ощутила ответственность за решения по проекту и задачи всей команды. Я училась делать свою работу хорошо и сильно выросла в навыках ведения переговоров и работы с информацией.
На тот момент мы все назывались бизнес-аналитиками. Не было деления на системных, продуктовых или аналитиков данных. Проектировали fullstack: от концепции до физического уровня.
Прошло всего-то лет 15, и названий аналитиков больше одного. Каждый считает свой путь единственно верным. Если пытаться стать тем, что в тренде, без учета вашего темперамента и склонностей, то ближе к завершению карьеры можно обнаружить себя героем рассказа Жванецкого: "Зато я скажу теперь сыну: "Парень, я прошел через всё. Я не стал этим и не стал тем. Я передам тебе свой опыт!"😊
Уже никто не назовет безумием мой диплом по математике. А вот когда называю себя бизнес-аналитиком, многие удивляются "как же такая взрослая и все БА". Теперь БА это уже не про fullstack и "изучение предметной области за три дня". Названия изменились, а мы с моим темпераментом все те же. И мы друг другу очень благодарны за профессиональный рост и возможность не застрять в роли, которая не по душе 🌱
Вопрос. Давайте подсчитаем в комментариях, сколько ролей вы уже сменили за карьеру?
#мысливслух #карьера
Дождь над Финским заливом, отпуск и новое в папке каналов "Про анализ". Встретила несколько постов о ролях аналитиков с комментариями в духе "Я вырос из БА до СА/ разработчика" – и задумалась. Почему принято называть ростом переход в другую роль, хотя это по сути смена навыков и контекста? Почему мы пытаемся оценивать карьеру какими-то ступенями, хотя это забег длиной в 40+ лет со сложными поворотами?
Знаете детский стих "Мама – летчик? Что ж такого!" с финалом "Дело было вечером, спорить было нечего." Так и слово "рост" в этом контексте, если разобраться, даже не предмет спора.
Когда я в середине девяностых планировала поступать на мех-мат, друзья и знакомые крутили пальцем у виска. Заводы закрывались, инженерам жилось непросто. Самые амбициозные шли поступать на экономистов или юристов. В моём вузе на математические специальности, скорее всего, был недобор. Родители убедили, что математика – это знание, из которого можно развиваться куда угодно. Не знаю, просчитывали ли они на 20 лет вперёд, но оказались правы: красный диплом по прикладной математике открыл мне многие возможности.
Первой строчкой в трудовой было "инженер-программист". Звучит солидно, но на деле оказалось пыткой для моего темперамента. Он с трудом выдерживал написание кода с 8:00 до 17:00 при минимуме общения. Терпение и дисциплина помогают решать задачи и временами меня хвалили, но запасы этих качеств за неполных три года истощились.
Примерно тогда же, когда закончилось терпение, в мой город пришла заказная разработка, а с ней - новые роли в производстве ПО. Так я оказалась в тестировании. Через пару лет я уже в роли QA лида и снова темперамент протестует против составления баг-репортов и тест-кейсов. Распределять задачи команде неплохо, но где же исследования и драйв неопределенности?
На мое счастье в проектах появились бизнес аналитики, которые много путешествовали по предприятиям заказчиков и на международных проектах постоянно практиковали английский. Здесь нам с моим темпераментом стало хорошо. Мы с темпераментом вечно с кем-то общались, мчались на вокзал или в аэропорт в любую погоду и даже 8го марта. Мои английский и немецкий из хобби превратились в инструмент для расшифровки кривых постановок от немецких заказчиков. Здесь я ощутила ответственность за решения по проекту и задачи всей команды. Я училась делать свою работу хорошо и сильно выросла в навыках ведения переговоров и работы с информацией.
На тот момент мы все назывались бизнес-аналитиками. Не было деления на системных, продуктовых или аналитиков данных. Проектировали fullstack: от концепции до физического уровня.
Прошло всего-то лет 15, и названий аналитиков больше одного. Каждый считает свой путь единственно верным. Если пытаться стать тем, что в тренде, без учета вашего темперамента и склонностей, то ближе к завершению карьеры можно обнаружить себя героем рассказа Жванецкого: "Зато я скажу теперь сыну: "Парень, я прошел через всё. Я не стал этим и не стал тем. Я передам тебе свой опыт!"😊
Уже никто не назовет безумием мой диплом по математике. А вот когда называю себя бизнес-аналитиком, многие удивляются "как же такая взрослая и все БА". Теперь БА это уже не про fullstack и "изучение предметной области за три дня". Названия изменились, а мы с моим темпераментом все те же. И мы друг другу очень благодарны за профессиональный рост и возможность не застрять в роли, которая не по душе 🌱
Вопрос. Давайте подсчитаем в комментариях, сколько ролей вы уже сменили за карьеру?
#мысливслух #карьера
Please open Telegram to view this post
VIEW IN TELEGRAM
Почему ТЗ есть, а результата нет? (подборка)
Когда-то переход от заказной разработки к внутренним проектам принес мне прозрение: настоящие исследования — это не просто поговорить с парой выделенных экспертов и сделать ТЗ из того, "что сказали". С тех пор я одержима поиском ответов на вопросы вида "чтобы что?" (оказывается, за ним скрываются самые важные инсайты).
В выходные наткнулась на очень качественный вебинар на эту тему (он первый в списке) и следом собралась небольшая подборка.
🎬Когда вроде все сделали правильно – а заказчик недоволен. Опытные коллеги-аналитики на учебном примере разобрали, что нужно понять для хорошего результата и какими инструментами. Действительно качественный материал, где затронуты и определение контекста, и анализ ключевых показателей, и поиск проблем через root cause analysis и диаграмму Исикавы.
📃Важные ингредиенты для выявления требований. Публикация в Дзен-версии этого канала. О нескольких ориентирах, которые мне помогают получать информацию для требований.
🔖Требования vs Реальность: Почему в ТЗ находят «дыры» и как это исправить. Здесь акцент именно на способы передачи информации, а не на выяснение проблем. Если честно, в этой статье мне почему-то не захотелось нажать на добавку кармы на Хабре, тем не менее есть вполне реалистичные примеры неполных требований и рекомендации по составлению документа ТЗ.
🗞Заметить слона, или Подводные грабли IT-проектов Автор статьи поделился своим мнением обо всем понемногу – об инфраструктурных вопросах, о сборе обратной связи от заказчика, о нюансах состава работ по ТЗ.
📃С кем важно говорить о требованиях на самом деле? Снова публикация в Дзен-версии этого канала. Здесь о нюансах выявления заинтересованных сторон.
#что_почитать
Когда-то переход от заказной разработки к внутренним проектам принес мне прозрение: настоящие исследования — это не просто поговорить с парой выделенных экспертов и сделать ТЗ из того, "что сказали". С тех пор я одержима поиском ответов на вопросы вида "чтобы что?" (оказывается, за ним скрываются самые важные инсайты).
В выходные наткнулась на очень качественный вебинар на эту тему (он первый в списке) и следом собралась небольшая подборка.
🎬Когда вроде все сделали правильно – а заказчик недоволен. Опытные коллеги-аналитики на учебном примере разобрали, что нужно понять для хорошего результата и какими инструментами. Действительно качественный материал, где затронуты и определение контекста, и анализ ключевых показателей, и поиск проблем через root cause analysis и диаграмму Исикавы.
📃Важные ингредиенты для выявления требований. Публикация в Дзен-версии этого канала. О нескольких ориентирах, которые мне помогают получать информацию для требований.
🔖Требования vs Реальность: Почему в ТЗ находят «дыры» и как это исправить. Здесь акцент именно на способы передачи информации, а не на выяснение проблем. Если честно, в этой статье мне почему-то не захотелось нажать на добавку кармы на Хабре, тем не менее есть вполне реалистичные примеры неполных требований и рекомендации по составлению документа ТЗ.
🗞Заметить слона, или Подводные грабли IT-проектов Автор статьи поделился своим мнением обо всем понемногу – об инфраструктурных вопросах, о сборе обратной связи от заказчика, о нюансах состава работ по ТЗ.
📃С кем важно говорить о требованиях на самом деле? Снова публикация в Дзен-версии этого канала. Здесь о нюансах выявления заинтересованных сторон.
#что_почитать
☀️Пятничный дайджест историй
Иногда вместо экспертных статей пишу истории "около IT" . Обычно эти тексты занимают у меня больше времени, чтобы личный опыт превратить в слова. Собрала здесь несколько текстов, вдруг вы пропустили что-то из этого?
📌История про детство и компьютер (который в детстве мне казался магическим и даже вредным, хотя у него было собственное имя)
📌 Аналитик с опытом может быть новичком! (о нюансах онбординга, зонтике в шкафу и ностальгии)
📌 Давний пост о мотивации и ориентире на результат (с цитатами из мультика и семейными историями)
📌 Как из меня не получилось звезды учебного ролика (и вообще не удалось быть собой)
📌 Учебный год и офферы (о фото в семейном архиве, пишущей машинке и опыте преподавания)
Может, у вас было что-то похожее? Делитесь!
#истории
Иногда вместо экспертных статей пишу истории "около IT" . Обычно эти тексты занимают у меня больше времени, чтобы личный опыт превратить в слова. Собрала здесь несколько текстов, вдруг вы пропустили что-то из этого?
📌История про детство и компьютер (который в детстве мне казался магическим и даже вредным, хотя у него было собственное имя)
📌 Аналитик с опытом может быть новичком! (о нюансах онбординга, зонтике в шкафу и ностальгии)
📌 Давний пост о мотивации и ориентире на результат (с цитатами из мультика и семейными историями)
📌 Как из меня не получилось звезды учебного ролика (и вообще не удалось быть собой)
📌 Учебный год и офферы (о фото в семейном архиве, пишущей машинке и опыте преподавания)
Может, у вас было что-то похожее? Делитесь!
#истории