Сегодня поговорим о том, как владельцу продукта (ПО) наладить контакт со своей командой разработки. Поговорим про то, как стоит действовать и чего стоит избегать, чтобы получить доверие команды. Делитесь со своими ПО, чтобы проверить, знают ли они эти правила?
#agile_который_работает
#владельцу_продукта
#настройка_процессов
https://oros-it.ru/blog/how-can-po-deal-with-it-team?utm_source=tg&utm_medium=article&utm_campaign=tg_post
#agile_который_работает
#владельцу_продукта
#настройка_процессов
https://oros-it.ru/blog/how-can-po-deal-with-it-team?utm_source=tg&utm_medium=article&utm_campaign=tg_post
Почему важно правильно описывать задачи на разработку?
Если задача описана правильно и содержит в себе всю необходимую информацию для ее реализации, то исполнителю не приходится отвлекаться от на уточнения деталей и ждать ответа, выходя при этом из контекста и меняя свое техническое решение под каждую новую деталь. При этом, хорошо описанная задача, сводит к минимум вероятность неточной оценки и нарушения сроков. Такая задача проработана при постановке, у нее понятна цель и целевая аудитория, а значит это всегда функционал, который действительно нужен и не будет отложен в долгий ящик после реализации.
Принимая во внимание всю важной правильной постановки задачи, мы собрали для вас все самое важное для правильного описания задачи в одной статье. Разберем, как правильно описывать задачу, что такое критерии готовности задачи к разработке, критерии готовности задачи и критерии приемки, и чем эти понятия отличаются друг от друга.
#agile_который_работает #владельцу_продукта
https://oros-it.ru/blog/how-create-tickets-for-development?utm_source=tg&utm_medium=article&utm_campaign=tg_post
Если задача описана правильно и содержит в себе всю необходимую информацию для ее реализации, то исполнителю не приходится отвлекаться от на уточнения деталей и ждать ответа, выходя при этом из контекста и меняя свое техническое решение под каждую новую деталь. При этом, хорошо описанная задача, сводит к минимум вероятность неточной оценки и нарушения сроков. Такая задача проработана при постановке, у нее понятна цель и целевая аудитория, а значит это всегда функционал, который действительно нужен и не будет отложен в долгий ящик после реализации.
Принимая во внимание всю важной правильной постановки задачи, мы собрали для вас все самое важное для правильного описания задачи в одной статье. Разберем, как правильно описывать задачу, что такое критерии готовности задачи к разработке, критерии готовности задачи и критерии приемки, и чем эти понятия отличаются друг от друга.
#agile_который_работает #владельцу_продукта
https://oros-it.ru/blog/how-create-tickets-for-development?utm_source=tg&utm_medium=article&utm_campaign=tg_post
Орос IT
Как правильно описывать задачи на разработку
В статье про самоорганизующиеся команды мы говорили о том, как важны для хорошо и правильно описанные задачи на разработку. Давайте поговорим о том, как создать условия для того, чтобы задачи всегда описывались правильно и как это правильное описание должно…
Навигация по каналу
У нас набралось уже довольно много материалов. Чтобы вы не терялись мы сделали удобную навигацию по тегам. Она будет всегда в закрепленных сообщениях и мы будем ее дополнять по мере появления новых рубрик.
#разборкейса - разборы кейсов, вы можете прислать свой кейс на почту info@itleadassist.io
#чеклист - бесплатные чеклисты
#agile_который_работает - материалы по Agile в том виде, который реально работает
#настройка_процессов - материалы по процесса в команде
#построение_команды - все о построении команды, от структуры до обязанностей каждой должности
#владельцу_продукта - все что будет полезно для представителей бизнеса
#тимлиду - все что будет полезно тимлиду и любому руководителю
#советы - рубрика советов и статьи с советами
#ответы_на_вопросы - ответы на ваши вопросы
У нас набралось уже довольно много материалов. Чтобы вы не терялись мы сделали удобную навигацию по тегам. Она будет всегда в закрепленных сообщениях и мы будем ее дополнять по мере появления новых рубрик.
#разборкейса - разборы кейсов, вы можете прислать свой кейс на почту info@itleadassist.io
#чеклист - бесплатные чеклисты
#agile_который_работает - материалы по Agile в том виде, который реально работает
#настройка_процессов - материалы по процесса в команде
#построение_команды - все о построении команды, от структуры до обязанностей каждой должности
#владельцу_продукта - все что будет полезно для представителей бизнеса
#тимлиду - все что будет полезно тимлиду и любому руководителю
#советы - рубрика советов и статьи с советами
#ответы_на_вопросы - ответы на ваши вопросы
Как правильно трактовать Agile-манифест
Часто неправильная трактовка Agile-манифеста вредит работе команды, приводит к неправильному построению процессов, переработкам и падению качества продукта. Поэтому очень важно не просто знать Agile-манифест, а уметь правильно его трактовать, чтобы он помогал строить эффективную работу над действительно правильным продуктом. Поэтому в нашей рубрике #agile_который_работает мы будем разбирать основные идеи и принципы Agile в ключе правильного построения работы. Начнем с общих подходов, которые нужно использовать при трактовке Agile-манифеста, а в следующих постах подробно разберем каждый пункт.
Одно не исключает другое
Во всех основных идеях манифеста мы читаем противопоставление, на пример: “люди и взаимодействие важнее процессов и инструментов”. И это “важнее” многих сбивает с толку. Частая ошибка заключается в том, что основные идеи трактуются как “одно исключает другое”. И это совершенно неверно. Ни в одной основной идея Agile одно не исключает другое. Они лишь расставляют приоритеты в спорных ситуация (не в каждодневной работе), но не говорят о том, что в Agile не должно быть процессов (весь Agile в общем-то помогает строить процессы) или о том, что вы должны отменить все свои официальные контракты. Без процессов и документооборота работа не строится и не должна. Agile это всегда про гибкость и именно ее отражают основные идеи. Позже мы разберем каждую из них подробнее, сейчас лишь сформулируем основную мысль: основные идеи Agile не про исключение, они про гибкость.
Используйте здравый смысл
Принципы Agile, также, как и идеи, не должны трактоваться как безусловные правила без исключений. Если работающее программное обеспечение - лучше измеритель прогресса, это ни в коем случае не значит, что это единственный показатель прогресса. И то что лучше работают самоорганизующиеся команды, не значит, что только они имеют право на существование. Не каждая команда со старта готова к самоорганизации, да и условия для этого еще нужно создать. Поэтому не рассматривайте основные принципы как нерушимую истину, смотрите на ситуацию и используйте здравый смысл, чтобы понять, как правильно применить этот принцип в своей команде.
Одно не должно противоречить другому
Хорошим помощником в правильной трактовке манифеста является сравнение решения со всеми остальными принципами. Часто люди знают только про “люди важнее процессов” и “изменения приветствуются даже на поздних стадиях” - это очень удобно для манипуляции командой и трактуется как “долой процессы - привет необдуманным изменениям на любых стадиях”. Но принципы Agile-манифеста не должны использоваться в отрыве от всего остального. Простая сверка с другими принципами подскажет, что и процессы важны и изменения должны вводится не во вред техническому совершенству, уважению к команде и постоянному темпу. Поэтому никогда не концентрируйтесь на одном принципе, проверяйте чтобы ваше трактование не противоречило другим принципам. Иначе ваши процессы начнут разваливаться.
Основная идея Agile - гибкость, ничто не должно противоречить ей
Agile в своем названии не просто так отражает гибкость. Это сама основа Agile. И манифест в первую очередь строится таким образом, чтобы помочь развернуть мышление в нужную сторону. Но чтобы не запутаться в трактовке манифеста всегда нужно помнить основную мысль, что работа должна строится на гибкости. Это значит, что взяв за основу основные фреймворки Agile вы должны в первую очередь смотреть на то работает ли все это для вашей конкретной команды. И если что-то для нее не работает, то оно должно гибко подстраиваться под вашу конкретную ситуацию. Если, на пример, вы работаете с людьми, которые не могут работать в личном взаимодействии и постоянно нарушают договоренности, то отменяйте для себя этот принцип, потому что он для вас не работает. Ставьте на первое место жесткие процессы и документирование любых договоренностей, потому что для вас это работает только так (по крайней мере на данном этапе). Потому что самый важный принцип Agile - гибкость, с помощью которой он идеально адаптируется под любые ситуации.
Часто неправильная трактовка Agile-манифеста вредит работе команды, приводит к неправильному построению процессов, переработкам и падению качества продукта. Поэтому очень важно не просто знать Agile-манифест, а уметь правильно его трактовать, чтобы он помогал строить эффективную работу над действительно правильным продуктом. Поэтому в нашей рубрике #agile_который_работает мы будем разбирать основные идеи и принципы Agile в ключе правильного построения работы. Начнем с общих подходов, которые нужно использовать при трактовке Agile-манифеста, а в следующих постах подробно разберем каждый пункт.
Одно не исключает другое
Во всех основных идеях манифеста мы читаем противопоставление, на пример: “люди и взаимодействие важнее процессов и инструментов”. И это “важнее” многих сбивает с толку. Частая ошибка заключается в том, что основные идеи трактуются как “одно исключает другое”. И это совершенно неверно. Ни в одной основной идея Agile одно не исключает другое. Они лишь расставляют приоритеты в спорных ситуация (не в каждодневной работе), но не говорят о том, что в Agile не должно быть процессов (весь Agile в общем-то помогает строить процессы) или о том, что вы должны отменить все свои официальные контракты. Без процессов и документооборота работа не строится и не должна. Agile это всегда про гибкость и именно ее отражают основные идеи. Позже мы разберем каждую из них подробнее, сейчас лишь сформулируем основную мысль: основные идеи Agile не про исключение, они про гибкость.
Используйте здравый смысл
Принципы Agile, также, как и идеи, не должны трактоваться как безусловные правила без исключений. Если работающее программное обеспечение - лучше измеритель прогресса, это ни в коем случае не значит, что это единственный показатель прогресса. И то что лучше работают самоорганизующиеся команды, не значит, что только они имеют право на существование. Не каждая команда со старта готова к самоорганизации, да и условия для этого еще нужно создать. Поэтому не рассматривайте основные принципы как нерушимую истину, смотрите на ситуацию и используйте здравый смысл, чтобы понять, как правильно применить этот принцип в своей команде.
Одно не должно противоречить другому
Хорошим помощником в правильной трактовке манифеста является сравнение решения со всеми остальными принципами. Часто люди знают только про “люди важнее процессов” и “изменения приветствуются даже на поздних стадиях” - это очень удобно для манипуляции командой и трактуется как “долой процессы - привет необдуманным изменениям на любых стадиях”. Но принципы Agile-манифеста не должны использоваться в отрыве от всего остального. Простая сверка с другими принципами подскажет, что и процессы важны и изменения должны вводится не во вред техническому совершенству, уважению к команде и постоянному темпу. Поэтому никогда не концентрируйтесь на одном принципе, проверяйте чтобы ваше трактование не противоречило другим принципам. Иначе ваши процессы начнут разваливаться.
Основная идея Agile - гибкость, ничто не должно противоречить ей
Agile в своем названии не просто так отражает гибкость. Это сама основа Agile. И манифест в первую очередь строится таким образом, чтобы помочь развернуть мышление в нужную сторону. Но чтобы не запутаться в трактовке манифеста всегда нужно помнить основную мысль, что работа должна строится на гибкости. Это значит, что взяв за основу основные фреймворки Agile вы должны в первую очередь смотреть на то работает ли все это для вашей конкретной команды. И если что-то для нее не работает, то оно должно гибко подстраиваться под вашу конкретную ситуацию. Если, на пример, вы работаете с людьми, которые не могут работать в личном взаимодействии и постоянно нарушают договоренности, то отменяйте для себя этот принцип, потому что он для вас не работает. Ставьте на первое место жесткие процессы и документирование любых договоренностей, потому что для вас это работает только так (по крайней мере на данном этапе). Потому что самый важный принцип Agile - гибкость, с помощью которой он идеально адаптируется под любые ситуации.
Как плохие владельцы продукта обманывают команду
Сегодня я хочу продолжить разбирать ошибки трактования Agile-манифеста и поговорить про ценность "Готовность к изменениям важнее следования первоначальному плану", которая искажается чаще всего и приносит больше всего вреда процессам в ИТ-компаниях.
Здесь я представлю краткий разбор, но за более подробным с примерами рекомендую все же почитать полный разбор на нашем блоге.
#agile_который_работает
Сегодня я хочу продолжить разбирать ошибки трактования Agile-манифеста и поговорить про ценность "Готовность к изменениям важнее следования первоначальному плану", которая искажается чаще всего и приносит больше всего вреда процессам в ИТ-компаниях.
Здесь я представлю краткий разбор, но за более подробным с примерами рекомендую все же почитать полный разбор на нашем блоге.
#agile_который_работает
Верхнеуровневая и точная оценка сроков
Сегодня хотел бы поговорить об оценке сроков, как со стороны исполнителя, так и со стороны руководителя. Последние 7-8 лет я участвую в оценке сроков, как на собственные задачи, так и на задачи команд и отделов в целом. Поэтому сразу хотелось бы сказать, что мы можем говорить о реальных сроках на задачи и верхнеуровневых оценках.
Верхнеуровневые оценки и работа с бизнесом
Верхнеуровневые оценки нужны для долгосрочного планирования и обычно их нужно давать по очень расплывчатым описаниям, но без этого, в рамках большинства бизнес процессов, невозможно строить планирование развития продукта. Основной проблемой тут является то, что сроки эти, естественно, никогда не бывают точными. Это понятно каждому исполнителю по причине отсутствия достаточного количества деталей для оценки. Однако, бизнес команда обычно очень сильно цепляется за такие сроки и потом начинаются интересные процессы согласования реальных сроков. Какого-то идеального решения я не знаю, советую закладывать хорошие запасы на максимально видимую постановку задачи. Не соглашайтесь на убеждения, что задача будет простой просто пока не ясно на сколько, скорректировать сроки в минус всегда можно без особых проблем и споров, а вот в плюс почти никогда не работает без проблем. Также, при каждой оценке приучайте коллег к пониманию, что сроки будут пересчитаны при детализации задач. С некоторыми в итоге это приведет к вполне конструктивному общению в рамках планирования.
Как собирать сроки с людей
С конкретными задачами, тоже все не очень ладно. Почти каждый руководитель понимает, что нужно делать наценку на непредвиденные ситуации, но, когда собирает информацию с исполнителей, забывает учить каждого этому простому подходу. В итоге обычно собираются очень оптимистичные сроки и запаса не хватает. Что же делать? Не требовать ответ с людей в моменте и даже не принимать его. Дайте людям все хорошо взвесить, найти проблемные места и заложить на это время. Я стараюсь собирать итог не раньше чем через день (если только не горящая задача, но такие обычно берутся в работу и делаются пока не будут готовы в первом приоритете). В итоге такой подход + ваша наценка, дадут неплохое представление о времени реализации задачи.
Как закладывать сроки разработчику
Будучи разработчиком, я тоже всегда продумывал все моменты, где что-то может пойти не так, где надо заложить времени и где могут понадобиться дополнительные усилия. Советую каждому не пытаться дать ответ о сроках сходу. Это довольно сложно, наш мозг любит отбрасывать «мелочи» при беглом просмотре, а из таких мелочей может состоять 80% времени реализации задачи. Берите время на проработку и оценку. Не пытайтесь угадывать, анализируйте и оценивайте.
В целом решать проблемы с точностью оценок нужно через адекватное восприятие невозможности всегда попадать на 100% и ретроспективы, на которых разбираться, что пошло не так и что можно улучшить. Главное пытаться устранить причины плохой оценки, а не искать виноватых.
Максим Шаламов.
#тимлиду #разработчику #agile_который_работает
Сегодня хотел бы поговорить об оценке сроков, как со стороны исполнителя, так и со стороны руководителя. Последние 7-8 лет я участвую в оценке сроков, как на собственные задачи, так и на задачи команд и отделов в целом. Поэтому сразу хотелось бы сказать, что мы можем говорить о реальных сроках на задачи и верхнеуровневых оценках.
Верхнеуровневые оценки и работа с бизнесом
Верхнеуровневые оценки нужны для долгосрочного планирования и обычно их нужно давать по очень расплывчатым описаниям, но без этого, в рамках большинства бизнес процессов, невозможно строить планирование развития продукта. Основной проблемой тут является то, что сроки эти, естественно, никогда не бывают точными. Это понятно каждому исполнителю по причине отсутствия достаточного количества деталей для оценки. Однако, бизнес команда обычно очень сильно цепляется за такие сроки и потом начинаются интересные процессы согласования реальных сроков. Какого-то идеального решения я не знаю, советую закладывать хорошие запасы на максимально видимую постановку задачи. Не соглашайтесь на убеждения, что задача будет простой просто пока не ясно на сколько, скорректировать сроки в минус всегда можно без особых проблем и споров, а вот в плюс почти никогда не работает без проблем. Также, при каждой оценке приучайте коллег к пониманию, что сроки будут пересчитаны при детализации задач. С некоторыми в итоге это приведет к вполне конструктивному общению в рамках планирования.
Как собирать сроки с людей
С конкретными задачами, тоже все не очень ладно. Почти каждый руководитель понимает, что нужно делать наценку на непредвиденные ситуации, но, когда собирает информацию с исполнителей, забывает учить каждого этому простому подходу. В итоге обычно собираются очень оптимистичные сроки и запаса не хватает. Что же делать? Не требовать ответ с людей в моменте и даже не принимать его. Дайте людям все хорошо взвесить, найти проблемные места и заложить на это время. Я стараюсь собирать итог не раньше чем через день (если только не горящая задача, но такие обычно берутся в работу и делаются пока не будут готовы в первом приоритете). В итоге такой подход + ваша наценка, дадут неплохое представление о времени реализации задачи.
Как закладывать сроки разработчику
Будучи разработчиком, я тоже всегда продумывал все моменты, где что-то может пойти не так, где надо заложить времени и где могут понадобиться дополнительные усилия. Советую каждому не пытаться дать ответ о сроках сходу. Это довольно сложно, наш мозг любит отбрасывать «мелочи» при беглом просмотре, а из таких мелочей может состоять 80% времени реализации задачи. Берите время на проработку и оценку. Не пытайтесь угадывать, анализируйте и оценивайте.
В целом решать проблемы с точностью оценок нужно через адекватное восприятие невозможности всегда попадать на 100% и ретроспективы, на которых разбираться, что пошло не так и что можно улучшить. Главное пытаться устранить причины плохой оценки, а не искать виноватых.
Максим Шаламов.
#тимлиду #разработчику #agile_который_работает
Как ограничения влияют на креативность
Думаю многие слышали о недавнем дефиците бумаги. Вот и я стала свидетелем этой проблемы и хочу с вами разобрать, чему мы можем научиться на этом примере. На днях мне нужно было посетить частную клинику. Обычно процесс посещения сопровождается выдачей листочка с направлением к врачу, затем врач свой листочек с проведенными процедурами отдает вам для оплаты. В этот же раз все было иначе. В регистратуре не выдали листочка, врач находил пациента по имени в компьютере. Так же проходила и оплата. Весь процесс полностью построен без использования бумаги. Мне сразу пришла мысль, что ничего не мешало сделать так и раньше, ведь процесс по сути не меняется. Но пока у вас нет дефицита, вам нет нужды задумываться об оптимизации процесса.
Ограничения пробуждают креатив
Это работает подобным образом в любой сфере. В готовке, стиле, построении процессов, написании кода - чем больше ограничения, тем более креативные решения рождают. При наличии ограничений вы вынуждены думать о том, что вам действительно нужно, а что можно отбросить. Вы больше задумываетесь о том, как построить решение, чтобы не тратить больше ресурсов, чем нужно. И этот принцип также является одной из главных движущих сил в Agile.
Ограничения и продукт
В разработке продукта также существуют ограничения, на пример, рабочая сила, время и стоимость. Часто они воспринимаются, как нечто негативное. Однако, без этих ограничений развитие продукта может пострадать также сильно, как и при слишком сильном дефиците этих ресурсов. Дефицит ресурсов заставляет команду думать о том, что в продукте действительно важно, а не делать все подряд. Когда сроки начинают поджимать, правильная стратегия это взять бэклог продукта и хорошенько подумать, что в этом бэклоге соответствует цели продукта или релиза, а что, возможно, лишнее для поставленной цели. Это делает продукт более выверенным и более нацеленным на тот результат, которого мы хотим достичь.
В этом, в том числе, помогают и цели, которые мы ставим на спринт. Они помогают фокусировать команду в моменты нехватки ресурсов. Являются направляющей, по которой нужно распределять усилия команды. Именно поэтому этих целей ни в коем случае не должно быть много - это убивает саму идею, которой они служат.
В целом, когда вы сталкиваетесь с какими-то ограничениями, постарайтесь не воспринимать их только негативно, подумайте над тем, как они вам помогают и что вы можете улучшить благодаря им.
Александра Шаламова.
#разработчику #agile_который_работает
Думаю многие слышали о недавнем дефиците бумаги. Вот и я стала свидетелем этой проблемы и хочу с вами разобрать, чему мы можем научиться на этом примере. На днях мне нужно было посетить частную клинику. Обычно процесс посещения сопровождается выдачей листочка с направлением к врачу, затем врач свой листочек с проведенными процедурами отдает вам для оплаты. В этот же раз все было иначе. В регистратуре не выдали листочка, врач находил пациента по имени в компьютере. Так же проходила и оплата. Весь процесс полностью построен без использования бумаги. Мне сразу пришла мысль, что ничего не мешало сделать так и раньше, ведь процесс по сути не меняется. Но пока у вас нет дефицита, вам нет нужды задумываться об оптимизации процесса.
Ограничения пробуждают креатив
Это работает подобным образом в любой сфере. В готовке, стиле, построении процессов, написании кода - чем больше ограничения, тем более креативные решения рождают. При наличии ограничений вы вынуждены думать о том, что вам действительно нужно, а что можно отбросить. Вы больше задумываетесь о том, как построить решение, чтобы не тратить больше ресурсов, чем нужно. И этот принцип также является одной из главных движущих сил в Agile.
Ограничения и продукт
В разработке продукта также существуют ограничения, на пример, рабочая сила, время и стоимость. Часто они воспринимаются, как нечто негативное. Однако, без этих ограничений развитие продукта может пострадать также сильно, как и при слишком сильном дефиците этих ресурсов. Дефицит ресурсов заставляет команду думать о том, что в продукте действительно важно, а не делать все подряд. Когда сроки начинают поджимать, правильная стратегия это взять бэклог продукта и хорошенько подумать, что в этом бэклоге соответствует цели продукта или релиза, а что, возможно, лишнее для поставленной цели. Это делает продукт более выверенным и более нацеленным на тот результат, которого мы хотим достичь.
В этом, в том числе, помогают и цели, которые мы ставим на спринт. Они помогают фокусировать команду в моменты нехватки ресурсов. Являются направляющей, по которой нужно распределять усилия команды. Именно поэтому этих целей ни в коем случае не должно быть много - это убивает саму идею, которой они служат.
В целом, когда вы сталкиваетесь с какими-то ограничениями, постарайтесь не воспринимать их только негативно, подумайте над тем, как они вам помогают и что вы можете улучшить благодаря им.
Александра Шаламова.
#разработчику #agile_который_работает
5 ошибок, делающих ваше ретро бесполезным
Ретроспектива - это одна из самых важных церемоний Agile, она помогает команде улучшать свои процессы и повышать эффективность от спринта к спринту. Но бывает так, что ретро есть, а улучшений нет. Давайте рассмотрим ошибки, которые могут быть этому причиной.
Ретро проводится нерегулярно
В погоне за сроками и бизнес целями команды часто жертвуют своими процессами, чтобы успеть свои основные задачи. И это само по себе уже очень большая ошибка. Именно процессы помогают не тратить время на лишнюю работу и успевать задачи в срок. Что касается ретро, то, во-первых, оно поможет выявить проблемы и исправить их в следующем спринте, что даст прирост производительности команды (мы ведь спешим правда?). Во-вторых, если не провести ретро сразу, то проблемы забудутся и их решение отложится до следующего инцидента (если после него снова не будет пропущено ретро). В-третьих, некоторые проблемы, не будучи отловленными у самых истоков, могут стрельнуть в будущем намного сильнее и иногда их уже очень сложно исправить.
На ретро не назначается ответственный за проблему
Итак, вы собрались на ретро, накидали проблем, сказали, что надо что-то с этим делать и пошли дальше работать. И проблемы пошли работать вместе с вами. Я наблюдала, как месяц за месяцем команды писали на ретро одни и те же проблемы, сокрушались над ними и через две недели процедура повторялась. Чтобы этого не происходило в вашей команде, для каждой проблемы должен быть назначен ответственный за ее решение, ему должны быть поставлены соответствующие задачи и выделено время на решение этой проблемы. Дальше задачи на решение проблем проходят обычный цикл, как и любые задачи на разработку. Лучше всего вести список для каждого ретро, где будет указано какая проблема обсуждалась и кто назначен ответственным. Так всегда можно будет просмотреть историю ретро и оценить их эффективность. Заведите правило: начинать ретро с проверки списка прошлой встречи.
На ретро приглашаются лишние люди
Многим людям тяжело говорить о проблемах. Поэтому, собирая состав ретро, важно помнить, что на встрече должны быть только люди из команды, которые могут свободно (насколько это возможно) общаться и обсуждать свои проблемы. На этих встречах не должно быть представителей бизнеса, какими бы друзьями вы с ними не были, и, в особенности, не должно быть незнакомых команде людей. Даже если вы с ребятами из соседнего отдела работали вместе в этом спринте, не надо звать их на ретро свой команды. Особенно хорошо нужно помнить об этом тимлидам, которые много общаются с представителями других команд и чувствуют себя с ними более свободно, думайте прежде всего о комфорте вашей команды, иначе рискуете получить ретро для галочки.
На ретро начинают искать решение проблемы
Еще один момент, о котором я как-то говорила в статье про правила проведения стендапа, на ретро не должно искаться полное решение проблемы, иначе встреча превратится в балаган. Во-первых, некоторые проблемы невозможно решить за 5 минут, начиная обсуждать решение проблемы, вы можете увязнуть надолго и за все ретро успеть обсудить только один вопрос (и то ни к чему не прийти). Во-вторых, помните, что в многофункциональных командах на ретро могут быть люди, которых не касается конкретная проблема, от обсуждения чужих проблем ваши коллеги только утомятся и потеряют интерес ко встрече. Проблема фиксируется, для нее выделяется ответственный и команда движется дальше.
У ретро нет ведущего
Здесь я скажу коротко - у совершенно любой встречи должен быть ведущий. И ретро здесь не исключение. Кто-то должен следить за правилами проведения ретро, фиксировать проблемы, следить за дисциплиной, помогать выбирать ответственного для проблемы. Конечно в идеале это скрам-мастер, но он есть не во всех командах. Тем не менее ведущий должен быть, иначе встреча будет не эффективной.
Надеюсь вам поможет разбор этих ошибок сделать вашу ретроспективу более эффективной. Если вам интересно больше узнать о церемониях Agile, то ставьте пальцы вверх этому посту и я напишу следующий.
Александра Шаламова
#agile_который_работает
Ретроспектива - это одна из самых важных церемоний Agile, она помогает команде улучшать свои процессы и повышать эффективность от спринта к спринту. Но бывает так, что ретро есть, а улучшений нет. Давайте рассмотрим ошибки, которые могут быть этому причиной.
Ретро проводится нерегулярно
В погоне за сроками и бизнес целями команды часто жертвуют своими процессами, чтобы успеть свои основные задачи. И это само по себе уже очень большая ошибка. Именно процессы помогают не тратить время на лишнюю работу и успевать задачи в срок. Что касается ретро, то, во-первых, оно поможет выявить проблемы и исправить их в следующем спринте, что даст прирост производительности команды (мы ведь спешим правда?). Во-вторых, если не провести ретро сразу, то проблемы забудутся и их решение отложится до следующего инцидента (если после него снова не будет пропущено ретро). В-третьих, некоторые проблемы, не будучи отловленными у самых истоков, могут стрельнуть в будущем намного сильнее и иногда их уже очень сложно исправить.
На ретро не назначается ответственный за проблему
Итак, вы собрались на ретро, накидали проблем, сказали, что надо что-то с этим делать и пошли дальше работать. И проблемы пошли работать вместе с вами. Я наблюдала, как месяц за месяцем команды писали на ретро одни и те же проблемы, сокрушались над ними и через две недели процедура повторялась. Чтобы этого не происходило в вашей команде, для каждой проблемы должен быть назначен ответственный за ее решение, ему должны быть поставлены соответствующие задачи и выделено время на решение этой проблемы. Дальше задачи на решение проблем проходят обычный цикл, как и любые задачи на разработку. Лучше всего вести список для каждого ретро, где будет указано какая проблема обсуждалась и кто назначен ответственным. Так всегда можно будет просмотреть историю ретро и оценить их эффективность. Заведите правило: начинать ретро с проверки списка прошлой встречи.
На ретро приглашаются лишние люди
Многим людям тяжело говорить о проблемах. Поэтому, собирая состав ретро, важно помнить, что на встрече должны быть только люди из команды, которые могут свободно (насколько это возможно) общаться и обсуждать свои проблемы. На этих встречах не должно быть представителей бизнеса, какими бы друзьями вы с ними не были, и, в особенности, не должно быть незнакомых команде людей. Даже если вы с ребятами из соседнего отдела работали вместе в этом спринте, не надо звать их на ретро свой команды. Особенно хорошо нужно помнить об этом тимлидам, которые много общаются с представителями других команд и чувствуют себя с ними более свободно, думайте прежде всего о комфорте вашей команды, иначе рискуете получить ретро для галочки.
На ретро начинают искать решение проблемы
Еще один момент, о котором я как-то говорила в статье про правила проведения стендапа, на ретро не должно искаться полное решение проблемы, иначе встреча превратится в балаган. Во-первых, некоторые проблемы невозможно решить за 5 минут, начиная обсуждать решение проблемы, вы можете увязнуть надолго и за все ретро успеть обсудить только один вопрос (и то ни к чему не прийти). Во-вторых, помните, что в многофункциональных командах на ретро могут быть люди, которых не касается конкретная проблема, от обсуждения чужих проблем ваши коллеги только утомятся и потеряют интерес ко встрече. Проблема фиксируется, для нее выделяется ответственный и команда движется дальше.
У ретро нет ведущего
Здесь я скажу коротко - у совершенно любой встречи должен быть ведущий. И ретро здесь не исключение. Кто-то должен следить за правилами проведения ретро, фиксировать проблемы, следить за дисциплиной, помогать выбирать ответственного для проблемы. Конечно в идеале это скрам-мастер, но он есть не во всех командах. Тем не менее ведущий должен быть, иначе встреча будет не эффективной.
Надеюсь вам поможет разбор этих ошибок сделать вашу ретроспективу более эффективной. Если вам интересно больше узнать о церемониях Agile, то ставьте пальцы вверх этому посту и я напишу следующий.
Александра Шаламова
#agile_который_работает
4 признака, что в вашей команде проблемы с процессами
Проблемы с процессами это слабое место многих компаний. Они напрямую ведут к потере прибыли, лишним тратам и созданию ненужного пользователю продукта. Самое коварное в ошибках процесса кроется в том, что они строятся на нашей психологии и мы можем даже не замечать, когда их совершаем. А самый важный шаг навстречу решению проблемы - осознать и признать ее наличие. Поэтому давайте разберем некоторые признаки, которые помогут вам выявить проблемы в процессах.
Постоянно вымотанная команда
Одно из последствий плохих процессов это переработки, которыми приходится компенсировать проседающий процесс. Переработки могут случатся в случае форс-мажора, но если компания на постоянной основе живет в таком ритме это признак плохо выстроенных процессов. От этого чаще всего страдает команда разработки и это можно заметить простым наблюдением. Люди уставшие, могут быть дергаными и нервными, с отсутствием инициативы и энтузиазма, общение в такой команде обычно не очень развито, потому что общаться никогда, да и не приветствуется.
Слишком много времени тратится на коммуникацию
Коммуникации невероятно важны в команде и могут помочь решить очень многие проблемы быстро и эффективно. Но иногда ими пытаются полностью заменить процессы. Если вы замечаете, что утопаете в коммуникациях, то стоит обратить внимание на правильность выстроенных процессов.
Начинаются новые фичи, когда старые еще не закончены
Нередко встречается такой стиль работы бизнеса, когда команде отдается крупный эпик, команда начинает его делать, и одновременно с этим бизнес приходит с новой большой фичей, которую срочно нужно делать. И такая работа ведется на постоянной основе. После этого на проекте обычно остаются части разного функционала, но единство продукта совершенно теряется. Здесь проблема в самом начале процесса - построении бизнес видения. Когда бизнес видение плохо составлено, то проект не сможет развиваться целостно, его будет мотать из одной стороны в другую.
Постоянные проверки руководителем
Случается, что руководитель, или представитель бизнеса, буквально стоит у вас над душой, когда вы решаете какую-то задачу. Постоянно пишет с вопросами: готова ли задача, а когда она будет готова, а чем сейчас занимаешься, а что потом будешь делать? Это все просто кричащий пример отсутствия процессов.
Таких признаков можно найти еще много, но эти встречаются чаще всего. Увидели в каком-то пункте свою команду? Тогда делитесь со своими коллегами, чтобы вместе обсудить проблему.
А мы пока готовим очень мощный материал по практическому применению Agile-практик. Тем, кто уже давно пробует Agile, он поможет понять, почему некоторые вещи не работают и как это исправить. А тем, кто никогда не работал с Agile, он поможет с нуля разобраться, как все должно работать именно на практике. Полный анонс будет чуть позже, так что оставайтесь с нами, вы все узнаете первыми!
Александра Шаламова
#agile_который_работает
Проблемы с процессами это слабое место многих компаний. Они напрямую ведут к потере прибыли, лишним тратам и созданию ненужного пользователю продукта. Самое коварное в ошибках процесса кроется в том, что они строятся на нашей психологии и мы можем даже не замечать, когда их совершаем. А самый важный шаг навстречу решению проблемы - осознать и признать ее наличие. Поэтому давайте разберем некоторые признаки, которые помогут вам выявить проблемы в процессах.
Постоянно вымотанная команда
Одно из последствий плохих процессов это переработки, которыми приходится компенсировать проседающий процесс. Переработки могут случатся в случае форс-мажора, но если компания на постоянной основе живет в таком ритме это признак плохо выстроенных процессов. От этого чаще всего страдает команда разработки и это можно заметить простым наблюдением. Люди уставшие, могут быть дергаными и нервными, с отсутствием инициативы и энтузиазма, общение в такой команде обычно не очень развито, потому что общаться никогда, да и не приветствуется.
Слишком много времени тратится на коммуникацию
Коммуникации невероятно важны в команде и могут помочь решить очень многие проблемы быстро и эффективно. Но иногда ими пытаются полностью заменить процессы. Если вы замечаете, что утопаете в коммуникациях, то стоит обратить внимание на правильность выстроенных процессов.
Начинаются новые фичи, когда старые еще не закончены
Нередко встречается такой стиль работы бизнеса, когда команде отдается крупный эпик, команда начинает его делать, и одновременно с этим бизнес приходит с новой большой фичей, которую срочно нужно делать. И такая работа ведется на постоянной основе. После этого на проекте обычно остаются части разного функционала, но единство продукта совершенно теряется. Здесь проблема в самом начале процесса - построении бизнес видения. Когда бизнес видение плохо составлено, то проект не сможет развиваться целостно, его будет мотать из одной стороны в другую.
Постоянные проверки руководителем
Случается, что руководитель, или представитель бизнеса, буквально стоит у вас над душой, когда вы решаете какую-то задачу. Постоянно пишет с вопросами: готова ли задача, а когда она будет готова, а чем сейчас занимаешься, а что потом будешь делать? Это все просто кричащий пример отсутствия процессов.
Таких признаков можно найти еще много, но эти встречаются чаще всего. Увидели в каком-то пункте свою команду? Тогда делитесь со своими коллегами, чтобы вместе обсудить проблему.
А мы пока готовим очень мощный материал по практическому применению Agile-практик. Тем, кто уже давно пробует Agile, он поможет понять, почему некоторые вещи не работают и как это исправить. А тем, кто никогда не работал с Agile, он поможет с нуля разобраться, как все должно работать именно на практике. Полный анонс будет чуть позже, так что оставайтесь с нами, вы все узнаете первыми!
Александра Шаламова
#agile_который_работает
Фокусировка - держим команду в фокусе
Важнейшей составляющей для любого успешного релиза является фокусировка. Это становится важнее с ростом размера релиза. Чем больший объем функционала вы хотите сделать (тем соответственно больше сроки реализации), тем важнее становится фактор фокусировки.
Мы всего лишь говорим об умении фокусироваться на главном и отбрасывать лишнее. Однако это бывает очень сложно, когда задач много и все они важные и нужные, а помогать выделить критичное никто не спешит.
Поставьте цели
Фокусировка начинается с малого, у каждого спринта или итерации, обязательно должна быть сформулирована цель. Все задачи работающие на выполнение цели, являются приоритетными и задача команды иметь приоритет на их решение. Все остальные задачи должны идти либо после выполнения цели, либо в случае, если у участников команды появляется время (сидеть и смотреть в монитор никому не нужно). Задача лидера команды все время держать фокус на важном. Переложить задачу на бизнес обычно не получается, потому что, в противном случае, задачи будут прибывать и прибывать. Все в команде должны понимать, что не закрытие цели спринта это отклонение от нормы и нужно разбираться в причинах (Как? Это тема отдельного разговора).
Расставьте приоритеты
Говоря про большие релизы, нужно сформировать не только цель, но и четко приоритезировать все задачи, связанные с целью. Приоритезация будет нужна, потому что в больших релизах от части запланированного функционала придется отказаться. Я рекомендую всегда уменьшать функционал, а не двигать сроки. Это позволяет минимально работать в стол и максимально быстро получить обратную связь от пользователей и понять идет ли все по плану или нет. Сдвиги сроков обычно сильно давят на команду и чем дальше, тем будет становиться хуже. Мое мнение на этот вопрос однозначное: ваша задача к дедлайну иметь работающий и отлаженный проект с набором критичного функционала. Очень важно, что работающего и отлаженного функционала, в который можно пускать пользователей. Тогда можно уже обсуждать в деталях, есть ли смысл в том, что получилось, и какой приоритет у доработок и следующих шагов. Если же вы приходите к дедлайну с набором недоделанных фичей, то ни о каком запуске речи быть не может, как и об успешной работе над взятым функционалом.
Что если бизнес не участвует в приоритезации
Если бизнес не может сам ставить приоритеты, то вам придется, слушая их, делать это самим. Тут очень простая логика, вам все равно нужно сделать каждую задачу в надлежащем качестве, поэтому если вы к дедлайну выберите и сделаете определенные, это как минимум ничего не испортит, как максимум - вы сможете запустить проект раньше. Если Бизнес приоритезирует задачи так, что они не влазят, то делаем тоже самое, выстраиваем максимально возможный по приоритету вариант.
В фокусировке важно, чтобы руководитель всегда доносил это до своих подчиненных, чтобы это не уходило у них из головы: есть цели и к ним нужно идти. Мы не должны умирать в пути к цели или делать плохой продукт. Мы должны искать варианты и обходные пути, где это возможно, а где это невозможно уменьшать число фичей или их сложность. Для руководителя очень важно не терять фокус самому и не переставать доносить важность этого до своей команды, тогда все получится. Найдутся и обходные пути, и результат придет.
Максим Шаламов
#тимлиду #agile_который_работает
Важнейшей составляющей для любого успешного релиза является фокусировка. Это становится важнее с ростом размера релиза. Чем больший объем функционала вы хотите сделать (тем соответственно больше сроки реализации), тем важнее становится фактор фокусировки.
Мы всего лишь говорим об умении фокусироваться на главном и отбрасывать лишнее. Однако это бывает очень сложно, когда задач много и все они важные и нужные, а помогать выделить критичное никто не спешит.
Поставьте цели
Фокусировка начинается с малого, у каждого спринта или итерации, обязательно должна быть сформулирована цель. Все задачи работающие на выполнение цели, являются приоритетными и задача команды иметь приоритет на их решение. Все остальные задачи должны идти либо после выполнения цели, либо в случае, если у участников команды появляется время (сидеть и смотреть в монитор никому не нужно). Задача лидера команды все время держать фокус на важном. Переложить задачу на бизнес обычно не получается, потому что, в противном случае, задачи будут прибывать и прибывать. Все в команде должны понимать, что не закрытие цели спринта это отклонение от нормы и нужно разбираться в причинах (Как? Это тема отдельного разговора).
Расставьте приоритеты
Говоря про большие релизы, нужно сформировать не только цель, но и четко приоритезировать все задачи, связанные с целью. Приоритезация будет нужна, потому что в больших релизах от части запланированного функционала придется отказаться. Я рекомендую всегда уменьшать функционал, а не двигать сроки. Это позволяет минимально работать в стол и максимально быстро получить обратную связь от пользователей и понять идет ли все по плану или нет. Сдвиги сроков обычно сильно давят на команду и чем дальше, тем будет становиться хуже. Мое мнение на этот вопрос однозначное: ваша задача к дедлайну иметь работающий и отлаженный проект с набором критичного функционала. Очень важно, что работающего и отлаженного функционала, в который можно пускать пользователей. Тогда можно уже обсуждать в деталях, есть ли смысл в том, что получилось, и какой приоритет у доработок и следующих шагов. Если же вы приходите к дедлайну с набором недоделанных фичей, то ни о каком запуске речи быть не может, как и об успешной работе над взятым функционалом.
Что если бизнес не участвует в приоритезации
Если бизнес не может сам ставить приоритеты, то вам придется, слушая их, делать это самим. Тут очень простая логика, вам все равно нужно сделать каждую задачу в надлежащем качестве, поэтому если вы к дедлайну выберите и сделаете определенные, это как минимум ничего не испортит, как максимум - вы сможете запустить проект раньше. Если Бизнес приоритезирует задачи так, что они не влазят, то делаем тоже самое, выстраиваем максимально возможный по приоритету вариант.
В фокусировке важно, чтобы руководитель всегда доносил это до своих подчиненных, чтобы это не уходило у них из головы: есть цели и к ним нужно идти. Мы не должны умирать в пути к цели или делать плохой продукт. Мы должны искать варианты и обходные пути, где это возможно, а где это невозможно уменьшать число фичей или их сложность. Для руководителя очень важно не терять фокус самому и не переставать доносить важность этого до своей команды, тогда все получится. Найдутся и обходные пути, и результат придет.
Максим Шаламов
#тимлиду #agile_который_работает
Алгоритм подготовки и проведения любой встречи
Сложно переоценить важность взаимодействия людей при работе над любым проектом. Не смотря на то, что это является одной из ключевых частей нашей работы, проводить встречи эффективно умеют не многие. Чтобы каждый раз не думать о том, как лучше провести встречу, я составила для вас небольшой алгоритм, который может стать основой для подготовки большинства встреч.
1. Определите тему и цели встречи. Как ни парадоксально это звучит, но иногда об этом пункте забывают. Прежде чем собирать кого бы то ни было, нужно определить зачем вы встречаетесь, какая цель у этой встречи, что в итоге вы должны получить в конце обсуждения.
2. Определите участников встречи. Хорошо подумайте над тем, кто вам действительно нужен для обсуждения. Не приглашайте лишних людей, они могут мешать эффективному общению, а вы потратите их время зря.
3. Определите ведущего встречи. У любой встречи должен быть человек, который направляет общение и следит, чтобы участники двигались к выполнению цели встречи. Это поможет провести встречу эффективно и поддерживать порядок.
4. Заранее спланируйте встречу в удобное для участников время. Лучше всего использовать для планирования встречи календарь с расписанием коллег, чтобы не получилось конфликтов между встречами. Стоит заранее узнать, не будет ли отсутствовать кто-то из обязательных участников встречи в этот день и не будет ли кто-то занят, чтобы такие детали не выяснились, когда все уже собрались и не сорвали встречу.
5. Заранее огласите тему и цели встречи участникам. Это можно также сделать через календарь, рассылая приглашения. Опишите для участников зачем вы их собираете и какую цель хотите решить этой встречей. Во-первых, встречей без названия и подробностей можно заранее вывести человека из себя и он придет в неподходящем настрое для продуктивного общения, а может и вообще не прийти. Во-вторых, так вы даете участникам возможность подготовиться, собрать нужную информацию и так далее.
6. Готовьтесь ко встречам. Это относится абсолютно ко всем участникам и к организатору, и к ведущему, и к приглашенным. Все должны заранее посмотреть, что за встреча предстоит, посмотреть на цели, собрать нужную информацию.
7. Составьте план встречи. Ведущий должен заранее составить план встречи, расписать основные части встречи и прикинуть ограничение времени. Без следования плану, встреча может пройти совершенно неэффективно и целей достичь не получится.
8. Используйте ограничение времени. Если встреча подразумевает обсуждения и споры, ведущему стоит использовать таймер или просто следить за временем, чтобы ограничивать основные этапы встречи. Иногда спор может длится бесконечно и нужно определить момент, когда нужно принять решение, вне зависимости от того, пришли спорящие к согласию или нет.
9. Назначьте ответственных. Если во время встречи было решено принять какие-то меры или провести какие-то работы, то на них обязательно должен быть выбран ответственный, который продолжит дальнейшую работу. Это не обязательно должен быть конечный исполнитель, но задача должна быть на кого-то назначена, иначе обсуждение может остаться только обсуждением без реальных результатов.
10. Составьте резюме встречи и разошлите его участникам. В конце встречи ведущий должен оставить немного времени, чтобы подвести итоги встречи, записать информацию о принятых решениях и алгоритме дальнейших действий. Лучше всего составить небольшое письмо и разослать его всем участникам, как итог прошедшей встречи. Так у вас, в случае возвращения к обсуждаемому вопросу, будут задокументированы принятые решения и встречу не придется собирать снова.
Александра Шаламова
#чеклист #agile_который_работает
Сложно переоценить важность взаимодействия людей при работе над любым проектом. Не смотря на то, что это является одной из ключевых частей нашей работы, проводить встречи эффективно умеют не многие. Чтобы каждый раз не думать о том, как лучше провести встречу, я составила для вас небольшой алгоритм, который может стать основой для подготовки большинства встреч.
1. Определите тему и цели встречи. Как ни парадоксально это звучит, но иногда об этом пункте забывают. Прежде чем собирать кого бы то ни было, нужно определить зачем вы встречаетесь, какая цель у этой встречи, что в итоге вы должны получить в конце обсуждения.
2. Определите участников встречи. Хорошо подумайте над тем, кто вам действительно нужен для обсуждения. Не приглашайте лишних людей, они могут мешать эффективному общению, а вы потратите их время зря.
3. Определите ведущего встречи. У любой встречи должен быть человек, который направляет общение и следит, чтобы участники двигались к выполнению цели встречи. Это поможет провести встречу эффективно и поддерживать порядок.
4. Заранее спланируйте встречу в удобное для участников время. Лучше всего использовать для планирования встречи календарь с расписанием коллег, чтобы не получилось конфликтов между встречами. Стоит заранее узнать, не будет ли отсутствовать кто-то из обязательных участников встречи в этот день и не будет ли кто-то занят, чтобы такие детали не выяснились, когда все уже собрались и не сорвали встречу.
5. Заранее огласите тему и цели встречи участникам. Это можно также сделать через календарь, рассылая приглашения. Опишите для участников зачем вы их собираете и какую цель хотите решить этой встречей. Во-первых, встречей без названия и подробностей можно заранее вывести человека из себя и он придет в неподходящем настрое для продуктивного общения, а может и вообще не прийти. Во-вторых, так вы даете участникам возможность подготовиться, собрать нужную информацию и так далее.
6. Готовьтесь ко встречам. Это относится абсолютно ко всем участникам и к организатору, и к ведущему, и к приглашенным. Все должны заранее посмотреть, что за встреча предстоит, посмотреть на цели, собрать нужную информацию.
7. Составьте план встречи. Ведущий должен заранее составить план встречи, расписать основные части встречи и прикинуть ограничение времени. Без следования плану, встреча может пройти совершенно неэффективно и целей достичь не получится.
8. Используйте ограничение времени. Если встреча подразумевает обсуждения и споры, ведущему стоит использовать таймер или просто следить за временем, чтобы ограничивать основные этапы встречи. Иногда спор может длится бесконечно и нужно определить момент, когда нужно принять решение, вне зависимости от того, пришли спорящие к согласию или нет.
9. Назначьте ответственных. Если во время встречи было решено принять какие-то меры или провести какие-то работы, то на них обязательно должен быть выбран ответственный, который продолжит дальнейшую работу. Это не обязательно должен быть конечный исполнитель, но задача должна быть на кого-то назначена, иначе обсуждение может остаться только обсуждением без реальных результатов.
10. Составьте резюме встречи и разошлите его участникам. В конце встречи ведущий должен оставить немного времени, чтобы подвести итоги встречи, записать информацию о принятых решениях и алгоритме дальнейших действий. Лучше всего составить небольшое письмо и разослать его всем участникам, как итог прошедшей встречи. Так у вас, в случае возвращения к обсуждаемому вопросу, будут задокументированы принятые решения и встречу не придется собирать снова.
Александра Шаламова
#чеклист #agile_который_работает
А как же куча встрееееееееч?
Одной из самых болезненных тем, при обсуждении спринтов является большое количество встреч, которые нужно проводить каждыйгребаный спринт. Эта куча встреч не дает честным разработчикам работать, а только отнимает время. Если честно, на эту тему можно говорить сутки на пролет и все равно всего не скажешь. Главное, что нужно помнить, каждая встреча должна и несет в себе определенный смысл. На пример, пункты выше как раз реализуются через эти самые встречи. А чтобы лучше понимать, зачем это все напридумывали, учите основы. Только зная основы и как определить приносит каждая встреча пользу или нет, можно понять нужна ли конкретная встреча вашей конкретной команде. Ну и не будем забывать, что встречи еще нужно и уметь проводить, об этом мы уже немного говорили раньше, но конечно же у каждой встречи есть свои особенности, опять же нужно учиться проводить каждую конкретную встречу правильно. А вообще отсутствие спринтов не спасет от кучи бесполезных встреч, они появляются от неумения строить правильные процессы и вести правильную коммуникацию, а не от выбора конкретных подходов.
Александра Шаламова
#agile_который_работает
Одной из самых болезненных тем, при обсуждении спринтов является большое количество встреч, которые нужно проводить каждый
Александра Шаламова
#agile_который_работает
Все, что вы знали об Agile неправда
Первое, что я в своей жизни узнала из Agile, были ежедневные стендапы в Яндексе в 2013 году. До этого я работала только в небольших отделах, которые вообще не пытались что-то делать с процессами, а работали как придется. Думаю большинство из нас именно так училось работать с задачами, повторяя за коллегами постарше и впитывая процессы своей текущей компании. Меня ни раз спрашивали на собеседованиях, какую последнюю книгу по разработке я прочитала, на какие ресурсы для разработчиков я подписана, но ни разу никто не интересовался, как я получаю знания об умении работать.
Мне тоже долго время казалось, что процессы это итак всем очевидная вещь. Однако, я начала что-то подозревать, когда об этих очевидных вещах мы с коллегами часами спорили на каждой встрече (Подумайте сколько стоит компании всего лишь один час споров о том, что такое цели спринта 10 человек? А во сколько бы вы оценили час своей собственной жизни?). Постоянные изменения условий задач во время разработки, переработки, огромное количество встреч, из-за которых некогда делать свою работу, систематическое нарушение сроков и переделки задач - это тоже все признаки непонимания, как работать с процессами, и их можно встретить практически в любой компании. В свое время я и вовсе разочаровалась в Agile, потому что видела, что компании, которые его применяют, работают неэффективно и мне самой не нравится так работать. Но все изменилось, когда я поняла в чем реальная суть и ценность Agile.
Проблема в том, что все обучения, которые проводятся в наших компаниях по процессам не стыкуются с той реальностью, которую мы каждый день наблюдаем. Мы вроде бы изучаем техники, но они постоянно конфликтуют с тем, что мы делаем на практике, все время остаются вопросы, что-то не сходится. В какой-то момент, мы с Максимом начали смотреть более глубоко информацию по Agile, в том числе, как он применяется в иностранных компаниях и расшифровывается гуру гибких методологий. Мы пытались выяснить: правда ли сама методология не работает или у нас неправильные вводные. Внезапно, мы обнаружили, что в большинстве наших компаний мы используем Agile вообще не так, как он задуман. И что ответы на те вопросы, которые нам мешают работать, уже есть, их просто нужно взять и использовать. Большинство команд передают друг другу или получают на обучениях лишь знания о конкретных техниках, они берут эти техники и натягивают их на свое привычное мышление и ежедневные проблемы, получая монстра, который не работает. А что мы получаем в результате, лично для себя, работая в таких командах? Мы работаем неэффективно, мы выматываемся, мы устаем от проекта, мы выгораем, мы увольняемся, а в новой компании все повторяется по кругу. В итоге мы разочаровываемся и виним технологию, а надо искать ее правильное применение в нашей каждодневной жизни.
В общем-то это одна из основных причин, по которой появился этот канал, чтобы рассказать о том, как взять правильное мышление и рабочие подходы, и применить их к нашей жизни и нашей реальности. Потому что она тоже отличается от международной и не все подходит нам из коробки. Именно по этой причине мы написали свою книгу про гибкие методологии, чтобы собрать и упорядочить то, что реально опробовано и работает в наших живых командах. Командах со своими вопросами, своими проблемами и своим менталитетом, уникальным для каждой отдела. Да, этому не учится каждый первый, возможно каждому первому это и не нужно (кого-то же должны использовать бизнес и компании, как им вздумается), этому не научишься за один день, но тот, кто встал на этот путь, откроет для себя дверь на новый уровень, недоступный большинству. А там уже каждому решать за себя, каким путем ему идти.
Александра Шаламова
#agile_который_работает
Первое, что я в своей жизни узнала из Agile, были ежедневные стендапы в Яндексе в 2013 году. До этого я работала только в небольших отделах, которые вообще не пытались что-то делать с процессами, а работали как придется. Думаю большинство из нас именно так училось работать с задачами, повторяя за коллегами постарше и впитывая процессы своей текущей компании. Меня ни раз спрашивали на собеседованиях, какую последнюю книгу по разработке я прочитала, на какие ресурсы для разработчиков я подписана, но ни разу никто не интересовался, как я получаю знания об умении работать.
Мне тоже долго время казалось, что процессы это итак всем очевидная вещь. Однако, я начала что-то подозревать, когда об этих очевидных вещах мы с коллегами часами спорили на каждой встрече (Подумайте сколько стоит компании всего лишь один час споров о том, что такое цели спринта 10 человек? А во сколько бы вы оценили час своей собственной жизни?). Постоянные изменения условий задач во время разработки, переработки, огромное количество встреч, из-за которых некогда делать свою работу, систематическое нарушение сроков и переделки задач - это тоже все признаки непонимания, как работать с процессами, и их можно встретить практически в любой компании. В свое время я и вовсе разочаровалась в Agile, потому что видела, что компании, которые его применяют, работают неэффективно и мне самой не нравится так работать. Но все изменилось, когда я поняла в чем реальная суть и ценность Agile.
Проблема в том, что все обучения, которые проводятся в наших компаниях по процессам не стыкуются с той реальностью, которую мы каждый день наблюдаем. Мы вроде бы изучаем техники, но они постоянно конфликтуют с тем, что мы делаем на практике, все время остаются вопросы, что-то не сходится. В какой-то момент, мы с Максимом начали смотреть более глубоко информацию по Agile, в том числе, как он применяется в иностранных компаниях и расшифровывается гуру гибких методологий. Мы пытались выяснить: правда ли сама методология не работает или у нас неправильные вводные. Внезапно, мы обнаружили, что в большинстве наших компаний мы используем Agile вообще не так, как он задуман. И что ответы на те вопросы, которые нам мешают работать, уже есть, их просто нужно взять и использовать. Большинство команд передают друг другу или получают на обучениях лишь знания о конкретных техниках, они берут эти техники и натягивают их на свое привычное мышление и ежедневные проблемы, получая монстра, который не работает. А что мы получаем в результате, лично для себя, работая в таких командах? Мы работаем неэффективно, мы выматываемся, мы устаем от проекта, мы выгораем, мы увольняемся, а в новой компании все повторяется по кругу. В итоге мы разочаровываемся и виним технологию, а надо искать ее правильное применение в нашей каждодневной жизни.
В общем-то это одна из основных причин, по которой появился этот канал, чтобы рассказать о том, как взять правильное мышление и рабочие подходы, и применить их к нашей жизни и нашей реальности. Потому что она тоже отличается от международной и не все подходит нам из коробки. Именно по этой причине мы написали свою книгу про гибкие методологии, чтобы собрать и упорядочить то, что реально опробовано и работает в наших живых командах. Командах со своими вопросами, своими проблемами и своим менталитетом, уникальным для каждой отдела. Да, этому не учится каждый первый, возможно каждому первому это и не нужно (кого-то же должны использовать бизнес и компании, как им вздумается), этому не научишься за один день, но тот, кто встал на этот путь, откроет для себя дверь на новый уровень, недоступный большинству. А там уже каждому решать за себя, каким путем ему идти.
Александра Шаламова
#agile_который_работает
“Я просто делаю, что мне говорят” - зачем разработчику уметь в процессы?
Мы много говорим о важности построения правильных взаимоотношений между разработкой и бизнесом. Конечно, в основном, этим занимаются руководители команд. Они должны задавать правила игры и следить, чтобы их выполняли обе стороны. Но влияет ли простой исполнитель на то, как происходит работа между ним и бизнесом? Или он человек подневольный и просто делает то, что говорят руководитель и бизнес-лидер?
Ломаем работу своего руководителя
Представьте ситуацию, руководитель отдела договаривается с бизнес-командой, что все работают по процессу, не приносят изменения в уже идущий спринт, формируют продуктовый бэклог заранее и т.д. Проходит много споров, но, в итоге, все соглашаются. В первый день спринта у владельца продукта происходит внезапная продажа клиентам не существующего функционала и созревает дикая необходимость втащить задачу не него “вот прям щас”. Приходит владелец продукта в команду, руководитель в это время на встрече, под руку попадается разработчик. Разработчику рассказывается, в какой ужасной ситуации мы все будем, если не сделаем эту задачу, что на кону репутация компании и срыв договора с клиентом, о том, как он подведет свою команду, да и вообще всю компанию, если сейчас же не сядет делать пол часа назад проданую клиенту задачу.
К моменту прихода руководителя с многочисленных встреч разработчик уже бросил все свои дела и сидит делает мега срочную задачу от владельца продукта. Если руководитель не дергает своих подчиненных почем зря, узнает он о ситуации только на следующем стендапе, то есть когда уже потеряны примерно сутки из спринта (для недельного спринта это очень много). Таким нехитрым способом разработчик пускает коту под хвост массу работы, сделанной его руководителем, и отменяет все договоренности с бизнес-командой, потому что они только что нашли лазейку, через которую будут ходить, когда им вздумается, ломая все процессы.
А что надо было делать?
Вы, возможно, спросите, а что надо было дать владельцу продукта сорвать контракт с клиентом? Во-первых, нужно знать основы работы с процессами, чтобы понять, когда они нарушаются и знать, как правильно вести себя в этой ситуации. Во-вторых, если кто-то нарушает процессы, то вы либо эскалируете проблему своему руководителю, который выстраивал эти договоренности, либо стоите на своих процессах, о которых вы все договорились, и тогда бизнесу самому придется идти к вашему руководителю и договариваться с ним, если он конечно вообще решится на это.
На любом уровне нужно помнить, что, если бизнес будет знать, что вы прогнетесь, когда ему нужно, он никогда не будет работать по процессам, потому что соблазн слишком велик. Он никогда не будет думать, что нужно спросить о сроках разработки прежде, чем давать кому-то обещания, что нельзя продавать то, чего не существует в проекте, и что техническая команда вообще является частью системы принятия решений (а она является, иначе техническое качество она обеспечивать не сможет). Найдутся единицы, которые сами понимают важность процессов, но с ними у вас эта ситуации и вовсе не возникнет.
Нарушая эти принципы, даже один разработчик может быть причиной отсутствия порядка в работе целой команды. Так мы зарабатываем собственные переработки и делаем проекты под переписывание, из которых сами же потом и увольняемся. Как этого избежать? Не ждать, когда руководитель ударит по шапке, если ты вот так ошибся и уже все сломал, а учиться, как должны работать процессы и работа с бизнесом заранее. Кроме изучения необходимых всем гибких методологий, где есть все и сразу, можете посмотреть наш более узкий мини-продукт по работе с бизнесом. Там мы как раз разбираем, как обычный разработчик должен правильно участвовать в работе с бизнесом, чтобы не стрелять себе же в ногу.
Александра Шаламова
#agile_который_работает
Мы много говорим о важности построения правильных взаимоотношений между разработкой и бизнесом. Конечно, в основном, этим занимаются руководители команд. Они должны задавать правила игры и следить, чтобы их выполняли обе стороны. Но влияет ли простой исполнитель на то, как происходит работа между ним и бизнесом? Или он человек подневольный и просто делает то, что говорят руководитель и бизнес-лидер?
Ломаем работу своего руководителя
Представьте ситуацию, руководитель отдела договаривается с бизнес-командой, что все работают по процессу, не приносят изменения в уже идущий спринт, формируют продуктовый бэклог заранее и т.д. Проходит много споров, но, в итоге, все соглашаются. В первый день спринта у владельца продукта происходит внезапная продажа клиентам не существующего функционала и созревает дикая необходимость втащить задачу не него “вот прям щас”. Приходит владелец продукта в команду, руководитель в это время на встрече, под руку попадается разработчик. Разработчику рассказывается, в какой ужасной ситуации мы все будем, если не сделаем эту задачу, что на кону репутация компании и срыв договора с клиентом, о том, как он подведет свою команду, да и вообще всю компанию, если сейчас же не сядет делать пол часа назад проданую клиенту задачу.
К моменту прихода руководителя с многочисленных встреч разработчик уже бросил все свои дела и сидит делает мега срочную задачу от владельца продукта. Если руководитель не дергает своих подчиненных почем зря, узнает он о ситуации только на следующем стендапе, то есть когда уже потеряны примерно сутки из спринта (для недельного спринта это очень много). Таким нехитрым способом разработчик пускает коту под хвост массу работы, сделанной его руководителем, и отменяет все договоренности с бизнес-командой, потому что они только что нашли лазейку, через которую будут ходить, когда им вздумается, ломая все процессы.
А что надо было делать?
Вы, возможно, спросите, а что надо было дать владельцу продукта сорвать контракт с клиентом? Во-первых, нужно знать основы работы с процессами, чтобы понять, когда они нарушаются и знать, как правильно вести себя в этой ситуации. Во-вторых, если кто-то нарушает процессы, то вы либо эскалируете проблему своему руководителю, который выстраивал эти договоренности, либо стоите на своих процессах, о которых вы все договорились, и тогда бизнесу самому придется идти к вашему руководителю и договариваться с ним, если он конечно вообще решится на это.
На любом уровне нужно помнить, что, если бизнес будет знать, что вы прогнетесь, когда ему нужно, он никогда не будет работать по процессам, потому что соблазн слишком велик. Он никогда не будет думать, что нужно спросить о сроках разработки прежде, чем давать кому-то обещания, что нельзя продавать то, чего не существует в проекте, и что техническая команда вообще является частью системы принятия решений (а она является, иначе техническое качество она обеспечивать не сможет). Найдутся единицы, которые сами понимают важность процессов, но с ними у вас эта ситуации и вовсе не возникнет.
Нарушая эти принципы, даже один разработчик может быть причиной отсутствия порядка в работе целой команды. Так мы зарабатываем собственные переработки и делаем проекты под переписывание, из которых сами же потом и увольняемся. Как этого избежать? Не ждать, когда руководитель ударит по шапке, если ты вот так ошибся и уже все сломал, а учиться, как должны работать процессы и работа с бизнесом заранее. Кроме изучения необходимых всем гибких методологий, где есть все и сразу, можете посмотреть наш более узкий мини-продукт по работе с бизнесом. Там мы как раз разбираем, как обычный разработчик должен правильно участвовать в работе с бизнесом, чтобы не стрелять себе же в ногу.
Александра Шаламова
#agile_который_работает
Где граница, когда разработка может менять задачи бизнеса, а когда нет?
Прелесть самоорганизующихся команд в возможности отдать им задачу и забыть о ней. Мы, технари, можем в рамках своей работы, подстраивать решение задачи под обстоятельства, чтобы довести дело до конца. Однако, где проходит та черта, когда мы можем что-то поменять в задаче на свое усмотрение, не привлекая заказчика, а когда этого делать категорически не стоит?
Смотрите на свою бизнес-команду
Конечно же это границы, которые вы должны выстраивать совместно со своей бизнес-командой. Внимательно следите за реакцией бизнес-коллег на ваши действия, отмечайте, когда они остаются довольны, и особо запоминайте моменты, когда ваши действия вызвали возмущение. Это и есть та грань, за которую переходить не стоит. Со временем бизнес начинает вам больше доверять или наоборот перестает доверять, если вы оплошали, поэтому эти границы могут сдвигаться и такое наблюдение и анализ должны быть постоянными.
Вы обязательно должны знать приоритеты и метрики своего бизнеса, чтобы понимать, что критично для вашего проекта. Например, если вы разрабатываете внутреннюю админку для компании, на ваш откуп могут полностью отдать внешний вид, где вы сможете делать все, как вам угодно, но вот функционал будет критично важен. На внешних промо-сайтах, заточенных под рекламную компанию, может быть важен каждый пиксель и любое внешнее изменение будет критично. Изучайте ваш бизнес, старайтесь в нем хорошо разбираться, чтобы разбираться, что важно, а что нет.
Где точно можно разгуляться?
Со своей стороны вы тоже должны выстраивать собственные границы. Вы отвечаете за качество проекта и все технические решения. Поэтому то, что вы на 100% можете менять в проекте это техническая сторона. Вы должны выбирать, как будет строится проект внутри. Если во время выполнения задачи вы поняли, что другое техническое решение подойдет лучше, а бизнес внешне получит тоже самое, то никакого отдельного подтверждения от вам здесь не нужно. Есть только один нюанс: нельзя менять техническое решение, если это затронет метрики бизнеса. Вы вольны делать с технической стороной проекта все, что вам нужно, пока по функционалу, по метрикам и по времени, затраченного командой на работу, для бизнеса ничего не меняется. Если вы вдруг решили потратить 2 месяца чистого времени на смену фреймворка, да еще и проект после этого стал работать в два раза медленнее, то бизнес вам точно спасибо не скажет. Оценивайте, насколько технические изменения касаются бизнеса, если они заметно сказываются на бизнес-части проекта, привлекайте к решению бизнес. Как правильно подавать свое решение и убеждать бизнес в необходимости изменений, мы подробно говорили в документации к работе с ПО,
Куда точно не стоит лезть?
Чего точно не стоит делать без участия бизнеса, так это менять сроки и состав заранее согласованных релизов и запусков. Бизнес должен однозначно решать, какой функционал должен стать доступен пользователю в каком составе. Иногда может казаться, что лучше сделать пол задачи и выкатить, чем не успеть все целиком, но для бизнеса половина задачи может быть либо юридически недопустимой, либо ломать пиар-компанию, которую месяц готовили и обещали совсем другое. Поэтому во всем, что касается изменения сроков и состава релизов, обязательно нужно консультироваться с бизнес-заказчиком и решать все изменения совместно.
Заведите правила
В идеале, вам с бизнесом нужно совместно составить четкие правила, что входит в их компетенцию, а что в вашу. Тогда вы просто работаете по этим правилам и все будут довольны. Конечно же каждую мелочь в правилах не опишешь, поэтому основные принципы стоит понимать.
В заключении, всегда нужно помнить, что мы с бизнесом одна команда. Всегда отталкиваетесь от этого и старайтесь заботится о своем проекте, думая в первую очередь о его будущем, а потом уже о всем остальном. Уважайте своих коллег и не пытайтесь их переиграть лишь бы сделать по-своему, но всегда отстаивайте реально необходимые изменения.
Александра Шаламова
#agile_который_работает
Прелесть самоорганизующихся команд в возможности отдать им задачу и забыть о ней. Мы, технари, можем в рамках своей работы, подстраивать решение задачи под обстоятельства, чтобы довести дело до конца. Однако, где проходит та черта, когда мы можем что-то поменять в задаче на свое усмотрение, не привлекая заказчика, а когда этого делать категорически не стоит?
Смотрите на свою бизнес-команду
Конечно же это границы, которые вы должны выстраивать совместно со своей бизнес-командой. Внимательно следите за реакцией бизнес-коллег на ваши действия, отмечайте, когда они остаются довольны, и особо запоминайте моменты, когда ваши действия вызвали возмущение. Это и есть та грань, за которую переходить не стоит. Со временем бизнес начинает вам больше доверять или наоборот перестает доверять, если вы оплошали, поэтому эти границы могут сдвигаться и такое наблюдение и анализ должны быть постоянными.
Вы обязательно должны знать приоритеты и метрики своего бизнеса, чтобы понимать, что критично для вашего проекта. Например, если вы разрабатываете внутреннюю админку для компании, на ваш откуп могут полностью отдать внешний вид, где вы сможете делать все, как вам угодно, но вот функционал будет критично важен. На внешних промо-сайтах, заточенных под рекламную компанию, может быть важен каждый пиксель и любое внешнее изменение будет критично. Изучайте ваш бизнес, старайтесь в нем хорошо разбираться, чтобы разбираться, что важно, а что нет.
Где точно можно разгуляться?
Со своей стороны вы тоже должны выстраивать собственные границы. Вы отвечаете за качество проекта и все технические решения. Поэтому то, что вы на 100% можете менять в проекте это техническая сторона. Вы должны выбирать, как будет строится проект внутри. Если во время выполнения задачи вы поняли, что другое техническое решение подойдет лучше, а бизнес внешне получит тоже самое, то никакого отдельного подтверждения от вам здесь не нужно. Есть только один нюанс: нельзя менять техническое решение, если это затронет метрики бизнеса. Вы вольны делать с технической стороной проекта все, что вам нужно, пока по функционалу, по метрикам и по времени, затраченного командой на работу, для бизнеса ничего не меняется. Если вы вдруг решили потратить 2 месяца чистого времени на смену фреймворка, да еще и проект после этого стал работать в два раза медленнее, то бизнес вам точно спасибо не скажет. Оценивайте, насколько технические изменения касаются бизнеса, если они заметно сказываются на бизнес-части проекта, привлекайте к решению бизнес. Как правильно подавать свое решение и убеждать бизнес в необходимости изменений, мы подробно говорили в документации к работе с ПО,
Куда точно не стоит лезть?
Чего точно не стоит делать без участия бизнеса, так это менять сроки и состав заранее согласованных релизов и запусков. Бизнес должен однозначно решать, какой функционал должен стать доступен пользователю в каком составе. Иногда может казаться, что лучше сделать пол задачи и выкатить, чем не успеть все целиком, но для бизнеса половина задачи может быть либо юридически недопустимой, либо ломать пиар-компанию, которую месяц готовили и обещали совсем другое. Поэтому во всем, что касается изменения сроков и состава релизов, обязательно нужно консультироваться с бизнес-заказчиком и решать все изменения совместно.
Заведите правила
В идеале, вам с бизнесом нужно совместно составить четкие правила, что входит в их компетенцию, а что в вашу. Тогда вы просто работаете по этим правилам и все будут довольны. Конечно же каждую мелочь в правилах не опишешь, поэтому основные принципы стоит понимать.
В заключении, всегда нужно помнить, что мы с бизнесом одна команда. Всегда отталкиваетесь от этого и старайтесь заботится о своем проекте, думая в первую очередь о его будущем, а потом уже о всем остальном. Уважайте своих коллег и не пытайтесь их переиграть лишь бы сделать по-своему, но всегда отстаивайте реально необходимые изменения.
Александра Шаламова
#agile_который_работает
Почему твой ПО тебя ненавидит
Представьте, что вы решили построить для себя дом мечты. Вы спланировали столько в нем будет этажей, какая будет калитка, какая дорожка, как будет приветливо потрескивать камин по вечерам, как здорово будет собираться вокруг него с друзьями, пить пиво, жарить шашлыки во дворе. Вы взяли кредит под стройку, позвали рабочих. И тут подходит к вам товарищ прораб и говорит: "ты знаешь, камин не получится сделать, трубу такую тут не приладить. Дорожку здесь проложить нельзя, только вон там. И окна будут смотреть не на этот твой яблоневый сад в цвету, а на болото с той стороны, но ты не понимаешь, так же будет лучше!". И тут твой дом мечты начинает разваливаться.
Вот так примерно и чувствуют себя бизнес, который уже нарисовал себе красивую картинку проекта или функционала, а потом пришли мы из этой своей разработки, и вместо того, чтобы просто сделать, начали задавать вопросы, предлагать какие-то свои решения, сроки двигать. А ему просто надо, чтобы вы сделали, как он хочет. А если это проект новый, то он вам еще и не доверяет. Откуда ему знать, что вы вообще знаете о чем говорите? А проверить он это может только рискнув своей репутацией и результатом. Только в отличии от дома, который ты строишь для себя, ему еще и начальство нагоняй за провал выдаст.
Стоит ли переть против ветра и давить? Так вы можете только усугубить ситуацию. Нужно аккуратно и постепенно формировать доверие и выстраивать отношения. Со временем вы сможете иметь все большее и большее влияние на проект. Когда хозяин дома почувствует, что вы заботитесь о том, чтобы ему жилось в нем лучше всего, он начнет вам доверять и давать принимать решения. Как этого добиться безболезненно и быстро мы разобрали тут.
Согласны с моим описанием или у вас другое видение? Делитесь в комментариях.
Александра Шаламова
#agile_который_работает
Представьте, что вы решили построить для себя дом мечты. Вы спланировали столько в нем будет этажей, какая будет калитка, какая дорожка, как будет приветливо потрескивать камин по вечерам, как здорово будет собираться вокруг него с друзьями, пить пиво, жарить шашлыки во дворе. Вы взяли кредит под стройку, позвали рабочих. И тут подходит к вам товарищ прораб и говорит: "ты знаешь, камин не получится сделать, трубу такую тут не приладить. Дорожку здесь проложить нельзя, только вон там. И окна будут смотреть не на этот твой яблоневый сад в цвету, а на болото с той стороны, но ты не понимаешь, так же будет лучше!". И тут твой дом мечты начинает разваливаться.
Вот так примерно и чувствуют себя бизнес, который уже нарисовал себе красивую картинку проекта или функционала, а потом пришли мы из этой своей разработки, и вместо того, чтобы просто сделать, начали задавать вопросы, предлагать какие-то свои решения, сроки двигать. А ему просто надо, чтобы вы сделали, как он хочет. А если это проект новый, то он вам еще и не доверяет. Откуда ему знать, что вы вообще знаете о чем говорите? А проверить он это может только рискнув своей репутацией и результатом. Только в отличии от дома, который ты строишь для себя, ему еще и начальство нагоняй за провал выдаст.
Стоит ли переть против ветра и давить? Так вы можете только усугубить ситуацию. Нужно аккуратно и постепенно формировать доверие и выстраивать отношения. Со временем вы сможете иметь все большее и большее влияние на проект. Когда хозяин дома почувствует, что вы заботитесь о том, чтобы ему жилось в нем лучше всего, он начнет вам доверять и давать принимать решения. Как этого добиться безболезненно и быстро мы разобрали тут.
Согласны с моим описанием или у вас другое видение? Делитесь в комментариях.
Александра Шаламова
#agile_который_работает
💯 Стопроцентный способ убить проект
Столкнулась тут с мнением:
"Это всяким там Яндексам и Сберам нужны метрики, у них бюджеты большие, пользователей много, планирование сложное, а на нашем маленьком проекте, который еле выживает, какие метрики? Они все только усложнят. Мы работаем на драйве и доверии, а не на метриках."
Ну что ж. Если вы так думаете, поздравляю, ваш проект никогда не станет большим, потому что просто загнется. А вам придется искать другую работу. Как человек, который уже несколько лет занимается бизнесом, могу сказать, что я поняла важность метрик для успеха бизнеса именно на супер маленьких проектах и бюджетах.
Если Google выделит миллион на пиар-компанию и она провалится, он это переживет, исправит проблему и пойдет дальше. Если маленький стартапер, который взял кредит на разработку, потратит 100 000р на пиар-компанию и она провалится, его бизнес закроется. Если Amazon перенесет кнопку "купить" в неудобное место, у него конечно может упасть конверсия, но люди скорее всего, все равно найдут, как им купить эту злосчастную сковородку. Если приложение с 100-200 пользователями, о котором никто никогда не слышал, перенесет кнопку "скачать" на своем сайте-визитке, никто не будет ее там искать, все просто уйдут.
Не поймите неправильно, большим компаниям тоже критично следить за метриками, но у них есть запас прочности и право на ошибку. Маленьким компаниям же ошибаться намного сложнее, а не увидеть свою ошибку вовремя может быть очень опасно. Поэтому именно для маленьких компаниям с маленькими бюджетами жизненно необходимо все обвешивать метриками и отслеживать их. Потому что любое падение трафика, конверсии или увеличение показателя отказов может стать критичным для бизнеса и принести убытки, с которыми он не сможет справится.
И это касается не только бизнеса, технические метрики не менее важны. Именно поэтому в нашей книге мы написали целый раздел по работе с метриками. Если вы все еще не умеете работать с метриками, то считайте это знаком, чтобы начать учиться. Поднимет вашу ценность, как специалиста, на любой позиции. А управленцам без этого вообще никуда.
Александра Шаламова
#agile_который_работает #agile #метрики
Столкнулась тут с мнением:
"Это всяким там Яндексам и Сберам нужны метрики, у них бюджеты большие, пользователей много, планирование сложное, а на нашем маленьком проекте, который еле выживает, какие метрики? Они все только усложнят. Мы работаем на драйве и доверии, а не на метриках."
Ну что ж. Если вы так думаете, поздравляю, ваш проект никогда не станет большим, потому что просто загнется. А вам придется искать другую работу. Как человек, который уже несколько лет занимается бизнесом, могу сказать, что я поняла важность метрик для успеха бизнеса именно на супер маленьких проектах и бюджетах.
Если Google выделит миллион на пиар-компанию и она провалится, он это переживет, исправит проблему и пойдет дальше. Если маленький стартапер, который взял кредит на разработку, потратит 100 000р на пиар-компанию и она провалится, его бизнес закроется. Если Amazon перенесет кнопку "купить" в неудобное место, у него конечно может упасть конверсия, но люди скорее всего, все равно найдут, как им купить эту злосчастную сковородку. Если приложение с 100-200 пользователями, о котором никто никогда не слышал, перенесет кнопку "скачать" на своем сайте-визитке, никто не будет ее там искать, все просто уйдут.
Не поймите неправильно, большим компаниям тоже критично следить за метриками, но у них есть запас прочности и право на ошибку. Маленьким компаниям же ошибаться намного сложнее, а не увидеть свою ошибку вовремя может быть очень опасно. Поэтому именно для маленьких компаниям с маленькими бюджетами жизненно необходимо все обвешивать метриками и отслеживать их. Потому что любое падение трафика, конверсии или увеличение показателя отказов может стать критичным для бизнеса и принести убытки, с которыми он не сможет справится.
И это касается не только бизнеса, технические метрики не менее важны. Именно поэтому в нашей книге мы написали целый раздел по работе с метриками. Если вы все еще не умеете работать с метриками, то считайте это знаком, чтобы начать учиться. Поднимет вашу ценность, как специалиста, на любой позиции. А управленцам без этого вообще никуда.
Александра Шаламова
#agile_который_работает #agile #метрики
Почему тяжело описывать задачи
Почему вообще столько сложностей возникает вокруг описания задач? Хотелось бы конечно сказать, что PO или заказчику просто лень это делать, но чаще всего все намного сложнее. Даже тем, кто реально готов стараться, сложно. Собственно поэтому мы и сделали свое руководство по описанию задач, которое с этим поможет. Так в чем же причина этих сложностей?
Бизнес (PO) и вообще любой заказчик, хорошо разбирается в своей области. Если это недвижимость, то в недвижимости, если машины, то в машинах, но вот в технической стороне бизнес подкован слабее. Поэтому то, что разработке кажется элементарным, людям целыми днями за компьютером не проводящим это не так уж и очевидно.
Как пример, заказчик хочет сделать кнопку подписки. У него в голове есть только это действие, ему нужно, чтобы человек подписался. Он наверное делал это сам когда-нибудь, но он даже не помнит, что там в интерфейсе происходило - нажал и забыл. Какая там валидация у поля, какие сообщения об успехе или ошибке могут быть, нужна ли галочка "согласен на обработку данных" и так далее. Это все просто не приходит в голову, потому что с этой стороны систему ты не знаешь. И это совершенно нормально! У каждого своя сфера, в которой он максимально силен.
В итоге заказчику ясно одно "я хочу кнопку подписаться" - все! И многие задачи на разработку именно так и выглядят. Одна фраза "сделай название фичи". А у разработчика при первом же взгляде на эту задачу появляется уйма вопросов.
Что можно сделать, если вы совсем не знаете, как поставить задачу и с чего вообще начать, мы описали в первой главе руководства. Пользуйтесь сами и делитесь со своими заказчиками. Кстати, не думайте, что если вы по задачам все время работаете, то вы сами умеете задачи описывать. Я тут недавно в очередной раз писала ТЗ для проекта, десять раз ловина себя на "ну это же очевидно". Но это уже совсем другая история.
Александра Шаламова
#agile_который_работает
Почему вообще столько сложностей возникает вокруг описания задач? Хотелось бы конечно сказать, что PO или заказчику просто лень это делать, но чаще всего все намного сложнее. Даже тем, кто реально готов стараться, сложно. Собственно поэтому мы и сделали свое руководство по описанию задач, которое с этим поможет. Так в чем же причина этих сложностей?
Бизнес (PO) и вообще любой заказчик, хорошо разбирается в своей области. Если это недвижимость, то в недвижимости, если машины, то в машинах, но вот в технической стороне бизнес подкован слабее. Поэтому то, что разработке кажется элементарным, людям целыми днями за компьютером не проводящим это не так уж и очевидно.
Как пример, заказчик хочет сделать кнопку подписки. У него в голове есть только это действие, ему нужно, чтобы человек подписался. Он наверное делал это сам когда-нибудь, но он даже не помнит, что там в интерфейсе происходило - нажал и забыл. Какая там валидация у поля, какие сообщения об успехе или ошибке могут быть, нужна ли галочка "согласен на обработку данных" и так далее. Это все просто не приходит в голову, потому что с этой стороны систему ты не знаешь. И это совершенно нормально! У каждого своя сфера, в которой он максимально силен.
В итоге заказчику ясно одно "я хочу кнопку подписаться" - все! И многие задачи на разработку именно так и выглядят. Одна фраза "сделай название фичи". А у разработчика при первом же взгляде на эту задачу появляется уйма вопросов.
Что можно сделать, если вы совсем не знаете, как поставить задачу и с чего вообще начать, мы описали в первой главе руководства. Пользуйтесь сами и делитесь со своими заказчиками. Кстати, не думайте, что если вы по задачам все время работаете, то вы сами умеете задачи описывать. Я тут недавно в очередной раз писала ТЗ для проекта, десять раз ловина себя на "ну это же очевидно". Но это уже совсем другая история.
Александра Шаламова
#agile_который_работает