Все, что вы знали об 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 #метрики