Я думаю, как я не старался сделать и просто и емко, где-то не совсем очевидны все посылы. Вот смотрите: "Иногда по-другому и не сделаешь, например, когда приходится аутсорсить разработку (на самом деле это не всегда так, но допустим). Но если есть возможность, то скорректировать содержание можно, не отказываясь от функционала, а пересматривая идеи и подходы к решению."
Это именно то, о чем вы говорите. Где-то нельзя. А что касается "Попробуйте что-то выпустить в большо enterprise без согласования, а я посмотрю", то я работал с PO, которые умеют даже в таких случаях проявить гибкость и даже на госзаказах гибко (причем реально закрывать, что не придерешься) закрыть требования. Мы с таким, закрыли гос заказ который все считали провальным. Причем заказ делался не под нас, так что к проверке подходили со всей строгостью. Конечно, главный функционал у нас работал как надо, а вот "заградительные" требования, которые пишутся, чтобы не допустить других участников, мы закрыли. И заказчику пришлось их принять. Опять же, не везде и не всегда такое возможно.
Встречный вопрос к "Если его нет - у вас проблема.". Допустим, проблема. Вот все остальные роли ок, а с PO, проблема. Что делать? Вопрос открытый. Я думаю, если вы напишите об этом статью и поделитесь своим опытом, то с удовольствием почитаю. И, думаю, не только я буду благодарен, если раскроете вопрос.
Я внимательно прочитал ваши замечания и хочу отметить, что приведённые иллюстрации в статье, на которые вы ссылаетесь, служат лишь для пояснения основного текста и не должны рассматриваться как отражение сути статьи. Они немного утрированы и представлены без всего контекста, который мог бы раскрыть более глубокое понимание ситуации.
Тем не менее, я добавлю чуточку информации.
Что касается программистов и аналитиков, то действительно, не каждый программист стремится быть аналитиком, и это нормально. Главное – уметь принимать и учитывать обратную связь от разработчиков. Когда они указывают на невозможность реализации того или иного решения, необходимо вести диалог и быть готовым к изменениям требований, а не оказывать давление. К тому же, в команде всегда найдутся те, кто хочет и может влиять на требования, и это ценно.
Пример с расширением для Google Chrome иллюстрирует, что команда может предложить альтернативные решения, которые могут быть более эффективными, даже если они не имеют долгосрочной перспективы. В мире быстрых изменений и неопределённости бизнес-процессов, решения с коротким жизненным циклом могут быть более предпочтительными, чем дорогостоящие и сложные системы, требующие значительных ресурсов для поддержки и модификации. В том примере был именно такой случай: писать дорого или быстро. Время жизни - несколько месяцев. Причем ценность была именно в скорости получения первого результата. Владелец продукта пришел с идеей сделать как в прошлый раз, т.к. технически даже не задумывался о варианте с расширением. Но команда преложила свое, Владелец продукта, хоть и бы не совсем уверен изначально, но в итоге поддержал команду.
Что касается примера с ненужным функционалом выбора региона, он опять же иллюстрирует предыдущий абзац, не более. То, как такое не допустить - отдельная тема и вы немного упомянули.
Вы абсолютно верно подметили, что даже в крупных структурах, где продакт-оунеру необходима поддержка аналитиков и маркетологов, можно наладить процесс таким образом, чтобы команда не только выполняла задачи, но и активно влияла на проект, внося свои предложения и получая возможность для обсуждения. В статье я действительно акцентирую внимание на ситуациях, когда требования предъявляются как непреложные истины, "прибитые гвоздями к стенке". Это противоречит не только принципам Agile, но и общепринятым методикам управления разработкой. Например, PMI ясно указывает на необходимость обсуждения требований с командой, что подтверждает важность совместной работы и гибкости в процессе разработки.
А то, что вы пишете про продуакт-оунера, это верно. В моём примере человека наняли, но по факту руководитель этого PO ввёл какой-то неадекватный менеджмент и жёсткие процессы, где не предоставлял PO необходимых полномочий. Собственно, мы c CEO это и исправили впоследствии.
Существуют необходимые и достаточные условия. Детализация требований командой является необходимым, но не достаточным условием. Так что с вашим комментарием полностью согласен.
Аджайл в жизни – это скорее о гибкости и адаптации, а не о хаотичных изменениях без ретроспективы. Возможно, таким товарищам стоит ввести в свою жизнь роли Product Owner и Scrum Master, чтобы задачи и изменения были более осмысленными и приводили к устойчивому развитию, а не к вечному циклу "спринтов" без достижения "инкрементов" счастья.
Лучше и не скажешь. Хотят прелести одного инструмента, но не учитывают, что он подходит тоже не для всего. И, как пишут в комментариях, натягивают сову на глобус.
Согласен с тем, что Agile тесно связан с управлением ожиданиями клиента. Часто вижу следующую картину: в рамках водопадной модели все требования прорабатываются до мелочей, а затем их передают команде с предложением "давайте в Agile-формате найдем способ сделать это подешевле". Естественно, команда что-то придумает, но не сможет сделать функционал дешевле, чем это возможно в принципе. Ситуация бы изменилась, если бы команде дали возможность предлагать изменения в функционале, чтобы решить проблему иным, более эффективным с точки зрения баланса функционала и технологий. Это не гарантирует нахождение решения, так что магии нет. Но если требования заранее зафиксированы, шансы решить проблему "побыстрее" стремятся к нулю.
Спасибо за комментарий. Я допускал вопрос про стоимость часа. Надо еще учесть что там был CEO и другие руководители. Плюс, если бы я сделал без подготовки, то все 10 минут были бы бессмысленны в принципе. Т.е. по факту, вместо 10 минут в пустую, 3.5 минуты имели конкретную цель. Еще, это я решил впервые выступить в таком формате, многое переосмыслил и в следующий раз это займет не более часа, а дальше еще меньше.
Основные идеи выделены в каждом разделе. Но без общего контекста они читаются сухо. Кому-то важен контекст. Но в целом, согласен. В следующий раз минимум в два раза короче статью сделаю.
10 человек в прямом подчинении - это действительно сложно.
За 2 недели человек может:
Устать от перегрузки в связи с какой-то задачей, обстоятельством или наложением личных проблем, недовольством кем-то из коллег, которые сотрудник не готов публично озвучивать. Первое с чего мы начинаем встречу - проясняем состояние. Мы держим руку на пульсе, чтобы не допустить выгорание.
Сотрудник может накопить вопросы и темы для обсуждения. Часто люди хотят о чем-то рассказать и получить обратную связь. Озвучить идеи, которые так же не решаются обсудить с командой.
Это возможность руководителю дать обратную связь, о чем-то важном рассказать или обсудить.
И да, бывают случаи, когда мы встречаемся раз в месяц. Вот только это одна 30-минутная встреча, посвященная сотруднику вместо множества мелких отвлечений, которые в совокупности могут привести к большим затратам.
Здесь согласен. Тут уже больше к руководству, считают ли они нормальным, что архитектор отвлекается на митинги, снижая производительность.
Вот прямо сегодня один из трех девелопмент менеджеров попросился на наш митинг, об оптимизации которого я говорил, т.к. тема пересекается с тем, за что он отвечает. Он тоже в таком формате был - работал) Но не думаю что это продуктивно. Будем решать, может ему проще получить какой-то сводный отчет о чем говорили и что решили, чем тратить время.
Очень здорово у вас регламентировано! Я бы тоже за такой формат, но команды хотят встречаться хотя бы виртуально раз в день. У нас удаленка. Вы в офисе работает или удаленно?
Привет! В проектах важно планировать на будущее и быть предсказуемыми. Простое добавление задачи в бэклог не решает проблему. Нужно либо выполнить задачу, либо решить не делать её вовсе. Если задача важна, но не выполняется, следует обсудить отмену, повышение приоритета или необходимость дополнительных ресурсов. Все задачи в бэклоге должны быть рассмотрены, так как их добавление изначально подразумевало важность. Обсуждение отмены может выявить ранее незамеченные аспекты задачи. Возможно, то что кажется важным кому-то, после прояснения потеряет свою важность. Тот кто заводит задачу, может просто не знать весь контекст. Я ответил на вопрос?
Отлично, что вам приглянулась идея! Будет непросто, но результат того стоит. Вопрос как подобное внедрять со стороны разработчиков в сторону менеджеров стоит отдельной статьи. Удачи!
Я думаю, как я не старался сделать и просто и емко, где-то не совсем очевидны все посылы. Вот смотрите:
"Иногда по-другому и не сделаешь, например, когда приходится аутсорсить разработку (на самом деле это не всегда так, но допустим). Но если есть возможность, то скорректировать содержание можно, не отказываясь от функционала, а пересматривая идеи и подходы к решению."
Это именно то, о чем вы говорите. Где-то нельзя. А что касается "Попробуйте что-то выпустить в большо enterprise без согласования, а я посмотрю", то я работал с PO, которые умеют даже в таких случаях проявить гибкость и даже на госзаказах гибко (причем реально закрывать, что не придерешься) закрыть требования. Мы с таким, закрыли гос заказ который все считали провальным. Причем заказ делался не под нас, так что к проверке подходили со всей строгостью. Конечно, главный функционал у нас работал как надо, а вот "заградительные" требования, которые пишутся, чтобы не допустить других участников, мы закрыли. И заказчику пришлось их принять. Опять же, не везде и не всегда такое возможно.
Встречный вопрос к "Если его нет - у вас проблема.". Допустим, проблема. Вот все остальные роли ок, а с PO, проблема. Что делать? Вопрос открытый. Я думаю, если вы напишите об этом статью и поделитесь своим опытом, то с удовольствием почитаю. И, думаю, не только я буду благодарен, если раскроете вопрос.
Я внимательно прочитал ваши замечания и хочу отметить, что приведённые иллюстрации в статье, на которые вы ссылаетесь, служат лишь для пояснения основного текста и не должны рассматриваться как отражение сути статьи. Они немного утрированы и представлены без всего контекста, который мог бы раскрыть более глубокое понимание ситуации.
Тем не менее, я добавлю чуточку информации.
Что касается программистов и аналитиков, то действительно, не каждый программист стремится быть аналитиком, и это нормально. Главное – уметь принимать и учитывать обратную связь от разработчиков. Когда они указывают на невозможность реализации того или иного решения, необходимо вести диалог и быть готовым к изменениям требований, а не оказывать давление. К тому же, в команде всегда найдутся те, кто хочет и может влиять на требования, и это ценно.
Пример с расширением для Google Chrome иллюстрирует, что команда может предложить альтернативные решения, которые могут быть более эффективными, даже если они не имеют долгосрочной перспективы. В мире быстрых изменений и неопределённости бизнес-процессов, решения с коротким жизненным циклом могут быть более предпочтительными, чем дорогостоящие и сложные системы, требующие значительных ресурсов для поддержки и модификации. В том примере был именно такой случай: писать дорого или быстро. Время жизни - несколько месяцев. Причем ценность была именно в скорости получения первого результата. Владелец продукта пришел с идеей сделать как в прошлый раз, т.к. технически даже не задумывался о варианте с расширением. Но команда преложила свое, Владелец продукта, хоть и бы не совсем уверен изначально, но в итоге поддержал команду.
Что касается примера с ненужным функционалом выбора региона, он опять же иллюстрирует предыдущий абзац, не более. То, как такое не допустить - отдельная тема и вы немного упомянули.
Вы абсолютно верно подметили, что даже в крупных структурах, где продакт-оунеру необходима поддержка аналитиков и маркетологов, можно наладить процесс таким образом, чтобы команда не только выполняла задачи, но и активно влияла на проект, внося свои предложения и получая возможность для обсуждения. В статье я действительно акцентирую внимание на ситуациях, когда требования предъявляются как непреложные истины, "прибитые гвоздями к стенке". Это противоречит не только принципам Agile, но и общепринятым методикам управления разработкой. Например, PMI ясно указывает на необходимость обсуждения требований с командой, что подтверждает важность совместной работы и гибкости в процессе разработки.
А то, что вы пишете про продуакт-оунера, это верно. В моём примере человека наняли, но по факту руководитель этого PO ввёл какой-то неадекватный менеджмент и жёсткие процессы, где не предоставлял PO необходимых полномочий. Собственно, мы c CEO это и исправили впоследствии.
Существуют необходимые и достаточные условия. Детализация требований командой является необходимым, но не достаточным условием. Так что с вашим комментарием полностью согласен.
Аджайл в жизни – это скорее о гибкости и адаптации, а не о хаотичных изменениях без ретроспективы. Возможно, таким товарищам стоит ввести в свою жизнь роли Product Owner и Scrum Master, чтобы задачи и изменения были более осмысленными и приводили к устойчивому развитию, а не к вечному циклу "спринтов" без достижения "инкрементов" счастья.
Лучше и не скажешь. Хотят прелести одного инструмента, но не учитывают, что он подходит тоже не для всего. И, как пишут в комментариях, натягивают сову на глобус.
Согласен с тем, что Agile тесно связан с управлением ожиданиями клиента. Часто вижу следующую картину: в рамках водопадной модели все требования прорабатываются до мелочей, а затем их передают команде с предложением "давайте в Agile-формате найдем способ сделать это подешевле". Естественно, команда что-то придумает, но не сможет сделать функционал дешевле, чем это возможно в принципе. Ситуация бы изменилась, если бы команде дали возможность предлагать изменения в функционале, чтобы решить проблему иным, более эффективным с точки зрения баланса функционала и технологий. Это не гарантирует нахождение решения, так что магии нет. Но если требования заранее зафиксированы, шансы решить проблему "побыстрее" стремятся к нулю.
Спасибо за комментарий. Я допускал вопрос про стоимость часа. Надо еще учесть что там был CEO и другие руководители. Плюс, если бы я сделал без подготовки, то все 10 минут были бы бессмысленны в принципе. Т.е. по факту, вместо 10 минут в пустую, 3.5 минуты имели конкретную цель. Еще, это я решил впервые выступить в таком формате, многое переосмыслил и в следующий раз это займет не более часа, а дальше еще меньше.
Основные идеи выделены в каждом разделе. Но без общего контекста они читаются сухо. Кому-то важен контекст. Но в целом, согласен. В следующий раз минимум в два раза короче статью сделаю.
10 человек в прямом подчинении - это действительно сложно.
За 2 недели человек может:
Устать от перегрузки в связи с какой-то задачей, обстоятельством или наложением личных проблем, недовольством кем-то из коллег, которые сотрудник не готов публично озвучивать. Первое с чего мы начинаем встречу - проясняем состояние. Мы держим руку на пульсе, чтобы не допустить выгорание.
Сотрудник может накопить вопросы и темы для обсуждения. Часто люди хотят о чем-то рассказать и получить обратную связь. Озвучить идеи, которые так же не решаются обсудить с командой.
Это возможность руководителю дать обратную связь, о чем-то важном рассказать или обсудить.
И да, бывают случаи, когда мы встречаемся раз в месяц. Вот только это одна 30-минутная встреча, посвященная сотруднику вместо множества мелких отвлечений, которые в совокупности могут привести к большим затратам.
Спасибо большое за обратную связь. Надеюсь, если вы решитесь поделиться моей статьёй, вам не придётся обсуждать её содержание на очередном совещании )
Я тоже не понимаю) Сегодня у меня было 3 часа непрерывных, но важных встречи 1 на 1, начиная с прямых подчиненных, заканчивая CEO. Я очень устал.
Здесь согласен. Тут уже больше к руководству, считают ли они нормальным, что архитектор отвлекается на митинги, снижая производительность.
Вот прямо сегодня один из трех девелопмент менеджеров попросился на наш митинг, об оптимизации которого я говорил, т.к. тема пересекается с тем, за что он отвечает. Он тоже в таком формате был - работал) Но не думаю что это продуктивно. Будем решать, может ему проще получить какой-то сводный отчет о чем говорили и что решили, чем тратить время.
Очень здорово у вас регламентировано! Я бы тоже за такой формат, но команды хотят встречаться хотя бы виртуально раз в день. У нас удаленка. Вы в офисе работает или удаленно?
Сами по себе статьи не помогут. На собеседовании поможет навык структурировать свои мысли, который немного подкачался этими статьями.
Абсолютно правы. Если кто-то не компетентен, то это отдельная тема. Поправил.
Такое случается потому, что руководителям часто есть куда развиваться. Опытные же теряют фокус.
Привет! В проектах важно планировать на будущее и быть предсказуемыми. Простое добавление задачи в бэклог не решает проблему. Нужно либо выполнить задачу, либо решить не делать её вовсе. Если задача важна, но не выполняется, следует обсудить отмену, повышение приоритета или необходимость дополнительных ресурсов. Все задачи в бэклоге должны быть рассмотрены, так как их добавление изначально подразумевало важность. Обсуждение отмены может выявить ранее незамеченные аспекты задачи. Возможно, то что кажется важным кому-то, после прояснения потеряет свою важность. Тот кто заводит задачу, может просто не знать весь контекст. Я ответил на вопрос?
Привет, Илья! Согласен. То о чем ты пишешь достойно отдельной публикации.
Отлично, что вам приглянулась идея! Будет непросто, но результат того стоит. Вопрос как подобное внедрять со стороны разработчиков в сторону менеджеров стоит отдельной статьи. Удачи!