Алгоритм подготовки и проведения любой встречи
Сложно переоценить важность взаимодействия людей при работе над любым проектом. Не смотря на то, что это является одной из ключевых частей нашей работы, проводить встречи эффективно умеют не многие. Чтобы каждый раз не думать о том, как лучше провести встречу, я составила для вас небольшой алгоритм, который может стать основой для подготовки большинства встреч.
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_который_работает