РОЗЫГРЫШ КНИГИ «Канбан Метод. Базовая практика» с автографом Алексея Пименова Ребят, подписывайтесь на канал и пишите в комментариях самые интересные/забавные/болезненные ситуации связанные с процессами, с которыми вы сталкивались при работе в компаниях. Мы с Лешей выберем 2 самых интересных коменатрия и подарим авторам комментариев книги. Подробности розыгрыша и даты объявим в канале - t.me/ulyanov_life
Очень болезненной ситуацией был проект, где сошлись звезды: 1) выгоревшая в ноль команда; 2) заранее фак-ап с объемом проекта - заказчик знал директора, папа заказчика был родственником одному из очень важных шишек в 2000 (семибанкирщина), директор ради такого кадра согласился на все; 3) менеджеры проекта ушли в свободное методологическое творчество и придумали а-ля канбан. В результате, команда сама себе заводила баги, успешно забрасывала релизы до их устранения, и бесился только директор+заказчик, потому что деньги проедены, а заказчик начинает выкручивать яйца. Канбан заключался в том, что пока баг не заборот - вся работа откладывалась 😁 В итоге, я не стал исключением - стал 8 менеджером, который ушел с этого проекта (и компании). Но нормальный такой кусок таки дотащил до релиза, и добился, чтобы его приняли и заказчик от него отстал. Данный продукт так и не появился на рынке, потому что пока шла полировка, уже 50 конкурентов заняли нишу.😆 P.S. Очень хочу книгу с Автографом, так как читаю электронку и хочу экземпляр на полку
Офигенный выпуск ребят, спасибо! Давно ловил себя на мысли, почему в 20 веке произошел прорыв от разделения труда и было написано много трудов, а сейчас все идут в кросс-функциональные команды везде поголовно, но кажется, тут все как и везде зависит от множества окружающих факторов. Сам менеджер проектов и по поводу "сварщика титана" призадумался, погуглю)).
Спасибо за обратную связь! Реально, часто стал встречаться с тем, что снова стараются сделать из разработчиков фуллстеков, но часто это заканчивается негативно для бизнеса и очень размывает ответственность за результат.
Расскажу смешной случай. Помню как стал проджектом и в первый раз пришел в айтишный проект. При передаче дел я затронул тему процессов и спрашиваю ПМа (который собирался уходить и как раз передавал дела мне по проекту) мол а как у вас выстроены процессы внутри команды? Ответ был короткий: пока не пнешь - не полетит. На первой же встрече с командой бизнес-аналитик говорит: - так, ну есть фича, планирую обсудить варианты реализации с заказчиком до конца недели. Проходит неделя, далее диалог: ПМ: - Привет. Ты хотел до конца недели с заказчиком проговорить варианты реализации фичи. Проговорил? БА: - Привет. Нет, не удалось пообщаться с заказчиком ПМ: - хм, странно, заказчик был постоянно на связи всю неделю. Почему не удалось? БА: - как это почему? ты мне встречу с заказчиком не организовал Пока не пнешь - не полетит
Не смешная ситуация, а наболевшие вопросы. Как сотруднику НЕ уровня топ-менеджер "бороться с бизнесом" при их желании внедрить модную систему, но без желания перестраивать свои процессы и помогать с разработкой и внедрением регламентов (особенно касающиеся изменения сроков в угоду качеству и отказа от техдолга, который потом так и не разбирают). И как влиять, если под "гибкостью" руководство понимает только желание постоянно влезать со своими задачами в планирование и спринты, но при этом желая получать новые фичи по построенному роадмапу без изменения командных ресурсов?
Ох... это крайне непростая ситуация, но я вижу здесь следующий выход: договариваться с своим руководителем, наглядно объясняя почему то, что хочет бизнес, невозможно реализовать в стабильный и стройный процесс деливери. Важно на фактах разобрать проблемы, которые проявляются из-за отсутствия приоритетов, постоянного "горящего" беклога и, желательно, предложить вариант изменения процессов, ссылаясь на метрики, почему такой процесс будет лучше и как бизнес от этого выиграет во времени/деньгам/поддержке/масштабировании и тп. Если после всех разложенных фактов и адекватных предложений изменений руководство не услышит и не предпримет никаких действий по улучшению, то стоит сменить компанию. Ну и да, если предлагаешь изменения, будь готов взять на себя ответственность за их внедрение. Иначе тебя могут послать, так как никто не любит добавления доп ответственности. При этом, проактивность любят и могут даже повысить, что, безусловно, будет хорошим кейсом и плюсом.
@@how-to-grow-up Тут больше даже про ситцацию, когда не прямое руководство не слышит или хочет слышать только удобное, а Руководство с большой буквы ака Владельцы бизнеса. Которые не хотят погружаться даже в проблемы ниже, им нужен только результат и прибыль
@@demeshnik с бизнесом нужно разговаривать на языке бизнеса, это факт. если то, что мы предлагаем, реально улучшит процессы, поможет срезать косты и/или повысить доходы, быстрее тестировать фичи и тп., то до бизнеса можно донести что изменения нужно. но это должны делать непосредственные руководители, сначала нужно продать им, а их задача эскалировать выше, так как прыгать через голову рисковано, можно стать потенциальной угрозой для собственного руководителя. иногда бизнесу реально пофиг на качество и просто нужно брать количеством, отъедать долю рынка. тогда и процессы нужно под это подстраивать, а не пытаться городить красоту архитектуры.
РОЗЫГРЫШ КНИГИ «Канбан Метод. Базовая практика» с автографом Алексея Пименова
Ребят, подписывайтесь на канал и пишите в комментариях самые интересные/забавные/болезненные ситуации связанные с процессами, с которыми вы сталкивались при работе в компаниях. Мы с Лешей выберем 2 самых интересных коменатрия и подарим авторам комментариев книги. Подробности розыгрыша и даты объявим в канале - t.me/ulyanov_life
Отличный выпуск! Спасибо!
Спасибо за обратную связь!
Информация - золото!
Специалисты - ТОП!
Почему так просмотров мало?
Даниил, большое спасибо за обратную связь! Канал развивающийся, набираем обороты.)
Благодаря таким активностям, как твоя, у нас все получится!
Очень болезненной ситуацией был проект, где сошлись звезды: 1) выгоревшая в ноль команда; 2) заранее фак-ап с объемом проекта - заказчик знал директора, папа заказчика был родственником одному из очень важных шишек в 2000 (семибанкирщина), директор ради такого кадра согласился на все; 3) менеджеры проекта ушли в свободное методологическое творчество и придумали а-ля канбан.
В результате, команда сама себе заводила баги, успешно забрасывала релизы до их устранения, и бесился только директор+заказчик, потому что деньги проедены, а заказчик начинает выкручивать яйца. Канбан заключался в том, что пока баг не заборот - вся работа откладывалась 😁
В итоге, я не стал исключением - стал 8 менеджером, который ушел с этого проекта (и компании). Но нормальный такой кусок таки дотащил до релиза, и добился, чтобы его приняли и заказчик от него отстал.
Данный продукт так и не появился на рынке, потому что пока шла полировка, уже 50 конкурентов заняли нишу.😆
P.S. Очень хочу книгу с Автографом, так как читаю электронку и хочу экземпляр на полку
Офигенный выпуск ребят, спасибо! Давно ловил себя на мысли, почему в 20 веке произошел прорыв от разделения труда и было написано много трудов, а сейчас все идут в кросс-функциональные команды везде поголовно, но кажется, тут все как и везде зависит от множества окружающих факторов.
Сам менеджер проектов и по поводу "сварщика титана" призадумался, погуглю)).
Спасибо за обратную связь!
Реально, часто стал встречаться с тем, что снова стараются сделать из разработчиков фуллстеков, но часто это заканчивается негативно для бизнеса и очень размывает ответственность за результат.
Очень круто, золото!
Кайф! Очень рад, что откликается!
Отличный подкаст и книжки любимые упомянули 🙂
@@Gedweb еееее! Андрей, спасибо 🙏🏼
Хороший выпуск! Понравился
@@Platon_Martin большое спасибо за обратную связь!!!
Расскажу смешной случай.
Помню как стал проджектом и в первый раз пришел в айтишный проект. При передаче дел я затронул тему процессов и спрашиваю ПМа (который собирался уходить и как раз передавал дела мне по проекту) мол а как у вас выстроены процессы внутри команды? Ответ был короткий: пока не пнешь - не полетит.
На первой же встрече с командой бизнес-аналитик говорит: - так, ну есть фича, планирую обсудить варианты реализации с заказчиком до конца недели.
Проходит неделя, далее диалог:
ПМ: - Привет. Ты хотел до конца недели с заказчиком проговорить варианты реализации фичи. Проговорил?
БА: - Привет. Нет, не удалось пообщаться с заказчиком
ПМ: - хм, странно, заказчик был постоянно на связи всю неделю. Почему не удалось?
БА: - как это почему? ты мне встречу с заказчиком не организовал
Пока не пнешь - не полетит
к сожалению, это база для многих компаний.) надеюсь, сейчас у вас не так все работает.)
Не смешная ситуация, а наболевшие вопросы. Как сотруднику НЕ уровня топ-менеджер "бороться с бизнесом" при их желании внедрить модную систему, но без желания перестраивать свои процессы и помогать с разработкой и внедрением регламентов (особенно касающиеся изменения сроков в угоду качеству и отказа от техдолга, который потом так и не разбирают). И как влиять, если под "гибкостью" руководство понимает только желание постоянно влезать со своими задачами в планирование и спринты, но при этом желая получать новые фичи по построенному роадмапу без изменения командных ресурсов?
Ох... это крайне непростая ситуация, но я вижу здесь следующий выход: договариваться с своим руководителем, наглядно объясняя почему то, что хочет бизнес, невозможно реализовать в стабильный и стройный процесс деливери. Важно на фактах разобрать проблемы, которые проявляются из-за отсутствия приоритетов, постоянного "горящего" беклога и, желательно, предложить вариант изменения процессов, ссылаясь на метрики, почему такой процесс будет лучше и как бизнес от этого выиграет во времени/деньгам/поддержке/масштабировании и тп.
Если после всех разложенных фактов и адекватных предложений изменений руководство не услышит и не предпримет никаких действий по улучшению, то стоит сменить компанию.
Ну и да, если предлагаешь изменения, будь готов взять на себя ответственность за их внедрение. Иначе тебя могут послать, так как никто не любит добавления доп ответственности. При этом, проактивность любят и могут даже повысить, что, безусловно, будет хорошим кейсом и плюсом.
@@how-to-grow-up Тут больше даже про ситцацию, когда не прямое руководство не слышит или хочет слышать только удобное, а Руководство с большой буквы ака Владельцы бизнеса. Которые не хотят погружаться даже в проблемы ниже, им нужен только результат и прибыль
@@demeshnik с бизнесом нужно разговаривать на языке бизнеса, это факт. если то, что мы предлагаем, реально улучшит процессы, поможет срезать косты и/или повысить доходы, быстрее тестировать фичи и тп., то до бизнеса можно донести что изменения нужно. но это должны делать непосредственные руководители, сначала нужно продать им, а их задача эскалировать выше, так как прыгать через голову рисковано, можно стать потенциальной угрозой для собственного руководителя.
иногда бизнесу реально пофиг на качество и просто нужно брать количеством, отъедать долю рынка. тогда и процессы нужно под это подстраивать, а не пытаться городить красоту архитектуры.
🩷💘🩷