#кейс_стади
Задача на подумать для менеджера
Правильного ответа нет. В таких случаях стоит задать допущения, опиши как бы ты действовал в комментариях к опросу
Ты работаешь в компании, разрабатывающей решения для токенизации карт — мобильные приложения, объединяющие карты лояльности, скидочные и банковские карты в единую систему. Продукт масштабируется, и из-за различий в регуляторных требованиях и особенностях маркетов каждая страна требует отдельной версии приложения. Регуляторные блокировки критичны: если приложение удаляют из маркета, продукт теряет рынок. Это вынуждает команду работать с высокой скоростью релизов, уделяя особое внимание их качеству
Когда ты пришел в компанию, основной акцент был сделан на организацию процессов и развитие технологических команд. После успешного прохождения испытательного срока эти ожидания закрепились, и твоя роль стала больше соответствовать позиции Delivery Manager: обеспечение бесперебойных поставок, минимизация рисков сбоев и управление ожиданиями бизнеса
И вот уже более полугода у тебя постоянное ощущение, что DevOps-процессы работают не так, как должны. Лид DevOps-команды, Вадим, технически очень силен, и это признают все. Однако как руководитель он не справляется. Он не выстраивает прозрачные процессы, не фиксирует договоренности, дает команде противоречивые указания. В результате возникают мелкие, но постоянные проблемы: задержки релизов, инфраструктурные сбои, ошибки в настройке дистрибуции и локальных сетей. Эти инциденты уже вызывают недовольство руководства и повышают риск серьезных операционных проблем
Ты обсуждал с Вадимом эту ситуацию. Он соглашается, что "не все идеально", но добродушно утверждает, что всё исправится. Каждый раз, когда что-то идет не так, он говорит: *«Разберусь»*, но ты не видишь, чтобы он брал на себя реальную ответственность или предпринимал системные шаги для решения проблем. Он скорее тушит пожары, чем предотвращает их
Ты уже попробовал несколько способов изменить ситуацию:
- Давал Вадиму развивающую обратную связь;
- Организовывал для него менторинг;
- Собирал на него широкоформатную обратную связь;
- Его руководитель даже открывал ему испытательный срок, но затем без объяснения причин закрыл его.
Ты также видишь, что Вадима не готовы промоутить дальше — его не рассматривают на более высокие роли. Но при этом его явно не хотят увольнять. Судя по всему, он ценный сотрудник для компании, и, возможно, руководство считает, что он лучше, чем возможные альтернативы
Ситуация сложная: если не предпринимать радикальных действий, проблемы продолжат накапливаться, релизы будут оставаться нестабильными, а недовольство сверху — расти. Вариант "пойти делать работу Вадима самому" кажется очевидным, но это означает, что ты начнешь выполнять за него работу, уходя от своей менеджерской роли
P.S. Весь ваш фидбэк учел и кейсы будут более конкретными, редкими, с вариантами и моим разбором
Задача на подумать для менеджера
Правильного ответа нет. В таких случаях стоит задать допущения, опиши как бы ты действовал в комментариях к опросу
Ты работаешь в компании, разрабатывающей решения для токенизации карт — мобильные приложения, объединяющие карты лояльности, скидочные и банковские карты в единую систему. Продукт масштабируется, и из-за различий в регуляторных требованиях и особенностях маркетов каждая страна требует отдельной версии приложения. Регуляторные блокировки критичны: если приложение удаляют из маркета, продукт теряет рынок. Это вынуждает команду работать с высокой скоростью релизов, уделяя особое внимание их качеству
Когда ты пришел в компанию, основной акцент был сделан на организацию процессов и развитие технологических команд. После успешного прохождения испытательного срока эти ожидания закрепились, и твоя роль стала больше соответствовать позиции Delivery Manager: обеспечение бесперебойных поставок, минимизация рисков сбоев и управление ожиданиями бизнеса
И вот уже более полугода у тебя постоянное ощущение, что DevOps-процессы работают не так, как должны. Лид DevOps-команды, Вадим, технически очень силен, и это признают все. Однако как руководитель он не справляется. Он не выстраивает прозрачные процессы, не фиксирует договоренности, дает команде противоречивые указания. В результате возникают мелкие, но постоянные проблемы: задержки релизов, инфраструктурные сбои, ошибки в настройке дистрибуции и локальных сетей. Эти инциденты уже вызывают недовольство руководства и повышают риск серьезных операционных проблем
Ты обсуждал с Вадимом эту ситуацию. Он соглашается, что "не все идеально", но добродушно утверждает, что всё исправится. Каждый раз, когда что-то идет не так, он говорит: *«Разберусь»*, но ты не видишь, чтобы он брал на себя реальную ответственность или предпринимал системные шаги для решения проблем. Он скорее тушит пожары, чем предотвращает их
Ты уже попробовал несколько способов изменить ситуацию:
- Давал Вадиму развивающую обратную связь;
- Организовывал для него менторинг;
- Собирал на него широкоформатную обратную связь;
- Его руководитель даже открывал ему испытательный срок, но затем без объяснения причин закрыл его.
Ты также видишь, что Вадима не готовы промоутить дальше — его не рассматривают на более высокие роли. Но при этом его явно не хотят увольнять. Судя по всему, он ценный сотрудник для компании, и, возможно, руководство считает, что он лучше, чем возможные альтернативы
Ситуация сложная: если не предпринимать радикальных действий, проблемы продолжат накапливаться, релизы будут оставаться нестабильными, а недовольство сверху — расти. Вариант "пойти делать работу Вадима самому" кажется очевидным, но это означает, что ты начнешь выполнять за него работу, уходя от своей менеджерской роли
P.S. Весь ваш фидбэк учел и кейсы будут более конкретными, редкими, с вариантами и моим разбором
🔥12👍2
#кейс_стади
Задача на подумать для менеджера. Разбор
Задача с Вадимом вызвал обсуждение, и неслучайно — у многих есть похожие ситуации, когда сильный технический специалист оказывается на управленческой роли, но не справляется. У каждого был/есть свой Вадим. Это не проблема Вадима как человека, это проблема системы, которая допустила такую ситуацию и не меняет её.
Проблема в том, что Вадим не на своём месте. Он хороший инженер, но не управляет процессами, не берет на себя ответственность и не фиксирует договоренности. Это приводит к постоянным задержкам, сбоям и росту недовольства. При этом его не увольняют и не продвигают, оставляя всё как есть, а значит эта ситуация для кого-то с геликоптер-вью что-то балансирует
В таких ситуациях решения нужно принимать одновременно в двух горизонтах:
1) Краткосрочное — найти костыль, который закроет управленческие провалы Вадима. Это может быть сотрудник в его команде, которому формально или неформально добавляются функции управления, или сам менеджер, который временно берет процессы на себя.
2) Долгосрочное — на позиции Вадима должен оказаться другой человек, обладающий не только техническими компетенциями, но и управленческими навыками
Обратная связь не всегда работает. И тем более не приводит к изменениям. Изменения случаются, если есть три условия:
- Представление о лучшем будущем
- Желание значимого лица изменить статус-кво
- Безопасные шаги для перехода к новой системе
Если этих факторов нет, любые разговоры о развитии останутся без последствий
Когда у сотрудника двойное подчинение и на него нельзя повлиять административно, а прийти вдвоём к решению не получилось, я иду к его руководителю. Формулирую ситуацию так: я понимаю, что ресурсов на разбор ситуации мало, есть более важные задачи, но проблема существует. Я не прошу вмешиваться немедленно, но предлагаю собрать кейсы и наглядно показать, как это влияет на проект
Дальше начинаю фиксировать всё в формате: дата – ситуация – пример (ссылка, скриншот) – что стоило сделать иначе. Когда накапливается достаточно данных, собираю кейс-эффект диаграмму, где фиксирую системные проблемы, их причины и следствия. Это даёт целостную картину: какие конкретно ошибки ведут к каким последствиям
Привязывать всё к метрикам или деньгам не всегда возможно. Я использовал такой подход всего один раз, и то притянуто за уши. Гораздо важнее показать влияние на операционные процессы и стабильность продукта
В ситуации с Вадимом я поступил именно так: за месяц собрал 22 кейса, визуализировал их влияние и представил его руководству. Этого оказалось достаточно. В итоге произошло перераспределение ролей среди DevOps-лидов, и к нам пришёл новый человек, который действительно занимался процессами. Стало проще и команде, и бизнес
P.S. Ситуация с моим Вадимом заняла почти год и это было действительно тяжело для меня, так как я не любитель собирать папки на людей
Задача на подумать для менеджера. Разбор
Задача с Вадимом вызвал обсуждение, и неслучайно — у многих есть похожие ситуации, когда сильный технический специалист оказывается на управленческой роли, но не справляется. У каждого был/есть свой Вадим. Это не проблема Вадима как человека, это проблема системы, которая допустила такую ситуацию и не меняет её.
Проблема в том, что Вадим не на своём месте. Он хороший инженер, но не управляет процессами, не берет на себя ответственность и не фиксирует договоренности. Это приводит к постоянным задержкам, сбоям и росту недовольства. При этом его не увольняют и не продвигают, оставляя всё как есть, а значит эта ситуация для кого-то с геликоптер-вью что-то балансирует
В таких ситуациях решения нужно принимать одновременно в двух горизонтах:
1) Краткосрочное — найти костыль, который закроет управленческие провалы Вадима. Это может быть сотрудник в его команде, которому формально или неформально добавляются функции управления, или сам менеджер, который временно берет процессы на себя.
2) Долгосрочное — на позиции Вадима должен оказаться другой человек, обладающий не только техническими компетенциями, но и управленческими навыками
Обратная связь не всегда работает. И тем более не приводит к изменениям. Изменения случаются, если есть три условия:
- Представление о лучшем будущем
- Желание значимого лица изменить статус-кво
- Безопасные шаги для перехода к новой системе
Если этих факторов нет, любые разговоры о развитии останутся без последствий
Когда у сотрудника двойное подчинение и на него нельзя повлиять административно, а прийти вдвоём к решению не получилось, я иду к его руководителю. Формулирую ситуацию так: я понимаю, что ресурсов на разбор ситуации мало, есть более важные задачи, но проблема существует. Я не прошу вмешиваться немедленно, но предлагаю собрать кейсы и наглядно показать, как это влияет на проект
Дальше начинаю фиксировать всё в формате: дата – ситуация – пример (ссылка, скриншот) – что стоило сделать иначе. Когда накапливается достаточно данных, собираю кейс-эффект диаграмму, где фиксирую системные проблемы, их причины и следствия. Это даёт целостную картину: какие конкретно ошибки ведут к каким последствиям
Привязывать всё к метрикам или деньгам не всегда возможно. Я использовал такой подход всего один раз, и то притянуто за уши. Гораздо важнее показать влияние на операционные процессы и стабильность продукта
В ситуации с Вадимом я поступил именно так: за месяц собрал 22 кейса, визуализировал их влияние и представил его руководству. Этого оказалось достаточно. В итоге произошло перераспределение ролей среди DevOps-лидов, и к нам пришёл новый человек, который действительно занимался процессами. Стало проще и команде, и бизнес
P.S. Ситуация с моим Вадимом заняла почти год и это было действительно тяжело для меня, так как я не любитель собирать папки на людей
👍30🔥9
#напутствие
Почему я работаю менеджером
Хороший процесс – это не только про то, чтобы гнать команды вперёд, но и про то, чтобы вовремя останавливаться. Так вот, ты тоже часть этого процесса
Работа – это марафон, а не спринт, и если долго игнорировать техдолг своего здоровья и психики, то однажды может прилететь такой факап, который никакими ретро не разберёшь. Хороший менеджер – это тот, кто не только умеет разруливать хаос, но и знает, когда пора сделать паузу. Давать команде передышку – это нормально. Снимать с собственной шеи маленького достигатора и отставать от себя - адекватно
Почему я работаю менеджером
Хороший процесс – это не только про то, чтобы гнать команды вперёд, но и про то, чтобы вовремя останавливаться. Так вот, ты тоже часть этого процесса
Работа – это марафон, а не спринт, и если долго игнорировать техдолг своего здоровья и психики, то однажды может прилететь такой факап, который никакими ретро не разберёшь. Хороший менеджер – это тот, кто не только умеет разруливать хаос, но и знает, когда пора сделать паузу. Давать команде передышку – это нормально. Снимать с собственной шеи маленького достигатора и отставать от себя - адекватно
👏36🔥12👍9
#кейс_стади
Задача на подумать для менеджера
Правильного ответа нет. В таких случаях стоит задать допущения, опиши как бы ты действовал в комментариях к опросу
Ты вышел на новое место работы — в крупную компанию, которая занимается доставкой цветов (конкурент Flowwow). Бизнес разросся, и вместе с ним выросла глобальная админ-панель для всего бэкофиса. В ней собрано буквально всё: управление партнерами, карточками товаров, логистика, CRM, финансы, маркетинг и еще десятки других систем, которые сплелись в один большой монолит
Эта админка уже давно тормозит развитие: у неё нет четкой архитектуры, любое изменение несет каскадный эффект, управлять доступами сложно, а стейкхолдеров так много, что их хотелки друг другу противоречат. Расти дальше на таком фундаменте невозможно — поэтому принято стратегическое решение распилить админку на микросервисы за год
Проект курирует лично Александр, CTO, который пришел из вашего крупнейшего конкурента и «знает, как это делать». Он уже участвовал в похожем проекте и уверен, что у него есть рабочий план. Тебе нужно просто обеспечить прозрачность процесса и следовать лучшим практикам
Вот только проблема в том, что никаких «лучших практик» не видно
Сначала казалось, что основная сложность — в масштабах системы. Но быстро выяснилось, что главная проблема — полное отсутствие понимания, что именно нужно делать. Тебе досталась новая команда, которая не писала этот монолит и плохо понимает, как он работает. Те, кто разрабатывал систему, давно уволились, документация фрагментарная, а код за годы правок превратился в неразбериху
Тебе поручили держать прозрачную отчетность и регулярно обновлять CTO по статусу проекта. Но чем глубже ты погружаешься, тем меньше понимаешь, что именно писать в этих отчетах
— Сколько осталось работы? Неизвестно, потому что никто не знает, сколько вообще всего есть в монолите.
— Какие сервисы уже готовы? Никакие, потому что пока только разбираетесь в системе.
— Какие следующие шаги? Хотелось бы ответить, но сначала надо разобраться, откуда тут столько неожиданных зависимостей.
Ты пробовал включить CTO в рабочие обсуждения, но это быстро обернулось катастрофой.
— Во-первых, он сразу пошел в микроменеджмент. Вместо стратегии начал разбирать конкретные таски и требовать «просто запустить что-то рабочее».
— Во-вторых, команда начала зажиматься. Разработчики и так перегружены — а теперь еще им приходится защищаться от вопросов вроде «Почему так долго?» и «Я видел это решается быстрее».
— В-третьих, отчеты не помогают. Ты пробовал описывать кейс, пробовал строить нечто вроде Ганта с прогрессом, пробовал еженедельные созвоны — ничего не заходит. CTO говорит, что ему нужны конкретные цифры и динамика
Но как дать динамику, если проект только распутывается, а не продвигается?
Ты понимаешь, что в таком режиме долго не протянешь. CTO давит, команда демотивирована, ты разрываешься между тем, чтобы защищать людей, и тем, чтобы давать хоть какую-то отчетность
Задача на подумать для менеджера
Правильного ответа нет. В таких случаях стоит задать допущения, опиши как бы ты действовал в комментариях к опросу
Ты вышел на новое место работы — в крупную компанию, которая занимается доставкой цветов (конкурент Flowwow). Бизнес разросся, и вместе с ним выросла глобальная админ-панель для всего бэкофиса. В ней собрано буквально всё: управление партнерами, карточками товаров, логистика, CRM, финансы, маркетинг и еще десятки других систем, которые сплелись в один большой монолит
Эта админка уже давно тормозит развитие: у неё нет четкой архитектуры, любое изменение несет каскадный эффект, управлять доступами сложно, а стейкхолдеров так много, что их хотелки друг другу противоречат. Расти дальше на таком фундаменте невозможно — поэтому принято стратегическое решение распилить админку на микросервисы за год
Проект курирует лично Александр, CTO, который пришел из вашего крупнейшего конкурента и «знает, как это делать». Он уже участвовал в похожем проекте и уверен, что у него есть рабочий план. Тебе нужно просто обеспечить прозрачность процесса и следовать лучшим практикам
Вот только проблема в том, что никаких «лучших практик» не видно
Сначала казалось, что основная сложность — в масштабах системы. Но быстро выяснилось, что главная проблема — полное отсутствие понимания, что именно нужно делать. Тебе досталась новая команда, которая не писала этот монолит и плохо понимает, как он работает. Те, кто разрабатывал систему, давно уволились, документация фрагментарная, а код за годы правок превратился в неразбериху
Тебе поручили держать прозрачную отчетность и регулярно обновлять CTO по статусу проекта. Но чем глубже ты погружаешься, тем меньше понимаешь, что именно писать в этих отчетах
— Сколько осталось работы? Неизвестно, потому что никто не знает, сколько вообще всего есть в монолите.
— Какие сервисы уже готовы? Никакие, потому что пока только разбираетесь в системе.
— Какие следующие шаги? Хотелось бы ответить, но сначала надо разобраться, откуда тут столько неожиданных зависимостей.
Ты пробовал включить CTO в рабочие обсуждения, но это быстро обернулось катастрофой.
— Во-первых, он сразу пошел в микроменеджмент. Вместо стратегии начал разбирать конкретные таски и требовать «просто запустить что-то рабочее».
— Во-вторых, команда начала зажиматься. Разработчики и так перегружены — а теперь еще им приходится защищаться от вопросов вроде «Почему так долго?» и «Я видел это решается быстрее».
— В-третьих, отчеты не помогают. Ты пробовал описывать кейс, пробовал строить нечто вроде Ганта с прогрессом, пробовал еженедельные созвоны — ничего не заходит. CTO говорит, что ему нужны конкретные цифры и динамика
Но как дать динамику, если проект только распутывается, а не продвигается?
Ты понимаешь, что в таком режиме долго не протянешь. CTO давит, команда демотивирована, ты разрываешься между тем, чтобы защищать людей, и тем, чтобы давать хоть какую-то отчетность
👍18🎉1👀1
Как добиться прозрачности, если ты сам не понимаешь, сколько впереди работы?
Anonymous Poll
27%
Провести штурм с командой — выделить ключевые домены, построить WBS и трекать прогресс в процентах
3%
Сфокусироваться на рисках — отказаться от плана и вести управление через риск-лог, вовлекая CTO
11%
Использовать бенчмарк CTO — построить роадмап, основываясь на его опыте в аналогичных проектах
26%
Применить набегающую волну — делать планирование по мере уточнения
9%
Работать через велосити — декомпозировать бэклог на равные части, строить прогноз по скорости
22%
Работать по принципу RnD - ограничивать итерации по 1 неделе,в конце менять план
4%
Твой вариант (напиши в комментариях)
#кейс_стади
Задача на подумать для менеджера
Распил монолита — это не просто технический рефакторинг, а стратегический проект. Как справедливо заметили в комментариях, разумно начинать с приоритизации функционала, который критичен для компании. Финансы, логистика, складской учет — в первую очередь. Остальное — по мере стабилизации первых сервисов и понимания архитектуры
После этого в ход идут принципы Disciplined Agile. Вместо жесткого roadmap — адаптивное планирование. Вместо жестких процессов — Way of Working . Стоит подходить к процессам не как к жестким рамкам, а как к пересматриваемому канвасу для удобства, чтобы не разбредаться. Из XP обязательно советую утащить 2 практики как костяк:
Small Releases - команда максимально часто выкатывает изменения, даже если это небольшие куски системы. Это позволяет избежать эффекта «мы три месяца копаемся и ничего не видно».
Planning Game - помогает на высоком уровне держать стратегическое видение, но без жесткого долгосрочного roadmap. Вместо этого есть набор ожидаемых изменений, который корректируется по мере изучения системы.
Но главный элемент этого подхода — обязательные демо. Без них CTO будет постоянно давить на скорость, а команда не будет получать внятную обратную связь.
Каждую неделю команда должна:
1. Показывать не просто код или записи, а работоспособные куски системы на стенде;
2. Получать обратную связь от тех, кто реально пользуется админкой;
3. Давать CTO возможность перепахивать бэклог, меняя приоритеты и набор задач;
Это критически важно. Без регулярной адаптации планов проект превратится в долгострой с фальшивой прозрачностью. CTO должен не просто смотреть отчеты, а быть вовлечен в пересборку стратегии раз в неделю.
Почему другие варианты не работают?
1. Классический WBS с процентами выполнения — дает ложное ощущение контроля. В реальности каждая новая неделя открывает столько неожиданностей, что «50% выполнено» не значит ничего;
2. Работа через списки рисков — CTO хочет не риски, а движение. Без привязки к реальным шагам риск-лог превращается в формальность;
3. Планирование по аналогии с прошлым опытом — у CTO может быть успешный бенчмарк, но если архитектура другая, этот опыт здесь не работает;
4. Прогнозирование через темп команды — пока команда занимается исследованием, темп разработки бесполезен;
5. Применить принцип набегающей волны — делать планирование по мере прояснения картины. На первый взгляд, это кажется разумным: фиксировать ближайшие задачи, а дальние уточнять позже. Проблема в том, что в условиях монолита даже ближайшие задачи — это гипотезы. Их выполнение открывает новые зависимости, что делает любое планирование на несколько итераций вперед практически бесполезным. Этот метод работает в проектах с прогнозируемой структурой, а здесь каждую неделю картина меняется настолько, что даже краткосрочный план нужно пересматривать
При таком подходе работа становится не хаотичной, а управляемой. Команда видит реальный прогресс, CTO получает динамику, а пользователи админки вовлекаются в процесс и помогают формировать продукт. Главное — не создавать иллюзию предсказуемости, а строить процесс так, чтобы он сам корректировал курс по мере движения
P.S. Конечно это невозможно без первичного кик-офа, общих договоренностей об архитектурном стиле и подготовки окружений. Если команда тратит более 5 минут в данном случае на развертывание - к распилу монолита на самом деле вы долго не продвинетесь
Задача на подумать для менеджера
Распил монолита — это не просто технический рефакторинг, а стратегический проект. Как справедливо заметили в комментариях, разумно начинать с приоритизации функционала, который критичен для компании. Финансы, логистика, складской учет — в первую очередь. Остальное — по мере стабилизации первых сервисов и понимания архитектуры
После этого в ход идут принципы Disciplined Agile. Вместо жесткого roadmap — адаптивное планирование. Вместо жестких процессов — Way of Working . Стоит подходить к процессам не как к жестким рамкам, а как к пересматриваемому канвасу для удобства, чтобы не разбредаться. Из XP обязательно советую утащить 2 практики как костяк:
Small Releases - команда максимально часто выкатывает изменения, даже если это небольшие куски системы. Это позволяет избежать эффекта «мы три месяца копаемся и ничего не видно».
Planning Game - помогает на высоком уровне держать стратегическое видение, но без жесткого долгосрочного roadmap. Вместо этого есть набор ожидаемых изменений, который корректируется по мере изучения системы.
Но главный элемент этого подхода — обязательные демо. Без них CTO будет постоянно давить на скорость, а команда не будет получать внятную обратную связь.
Каждую неделю команда должна:
1. Показывать не просто код или записи, а работоспособные куски системы на стенде;
2. Получать обратную связь от тех, кто реально пользуется админкой;
3. Давать CTO возможность перепахивать бэклог, меняя приоритеты и набор задач;
Это критически важно. Без регулярной адаптации планов проект превратится в долгострой с фальшивой прозрачностью. CTO должен не просто смотреть отчеты, а быть вовлечен в пересборку стратегии раз в неделю.
Почему другие варианты не работают?
1. Классический WBS с процентами выполнения — дает ложное ощущение контроля. В реальности каждая новая неделя открывает столько неожиданностей, что «50% выполнено» не значит ничего;
2. Работа через списки рисков — CTO хочет не риски, а движение. Без привязки к реальным шагам риск-лог превращается в формальность;
3. Планирование по аналогии с прошлым опытом — у CTO может быть успешный бенчмарк, но если архитектура другая, этот опыт здесь не работает;
4. Прогнозирование через темп команды — пока команда занимается исследованием, темп разработки бесполезен;
5. Применить принцип набегающей волны — делать планирование по мере прояснения картины. На первый взгляд, это кажется разумным: фиксировать ближайшие задачи, а дальние уточнять позже. Проблема в том, что в условиях монолита даже ближайшие задачи — это гипотезы. Их выполнение открывает новые зависимости, что делает любое планирование на несколько итераций вперед практически бесполезным. Этот метод работает в проектах с прогнозируемой структурой, а здесь каждую неделю картина меняется настолько, что даже краткосрочный план нужно пересматривать
При таком подходе работа становится не хаотичной, а управляемой. Команда видит реальный прогресс, CTO получает динамику, а пользователи админки вовлекаются в процесс и помогают формировать продукт. Главное — не создавать иллюзию предсказуемости, а строить процесс так, чтобы он сам корректировал курс по мере движения
P.S. Конечно это невозможно без первичного кик-офа, общих договоренностей об архитектурном стиле и подготовки окружений. Если команда тратит более 5 минут в данном случае на развертывание - к распилу монолита на самом деле вы долго не продвинетесь
🔥13👍8
#кейс_стади
Задача на подумать для менеджера
Правильного ответа нет. В таких случаях стоит задать допущения, опиши как бы ты действовал в комментариях к опросу
Постбэк на 14 февраля
Ты недавно зашёл в динамично растущую IT-компанию как деливери-менеджер. Тебе доверили присматривать за процессами и становиться «руководителем руководителей»: под твоим непрямым началом пять продуктовых стримов и команда проектных менеджеров. Компания только формирует культуру ответственности, внедряет карьерные треки и системы развития, и тут на сцену выходишь ты – с новыми идеями и желанием укрепить корпоративные стандарты.
Недавно ты ввел четкий карьерный трек для PM’ов и появились чёткие уровни развития, матрица компетенций и пути например “как из ПМа дорасти до деливери-менеджера” и далее
Самое любопытное, что в компании нет пока жёсткого комплаенса и кодекса поведения: всё на доверии и договорённостях. А по понедельникам люди расслабляются за настолками в офисе. На одном из таких неформальных вечеров к тебе проявляет явные знаки внимания Саша – один из PM’ов. Формально он/она тебе не подчиняется, но твой статус деливери-менеджера всё равно даёт тебе возможность влиять на развитие карьеры Саши: есть же единая система оценки, которую ты помогаешь поддерживать.
Тем временем, у тебя дома всё довольно шатко: партнёр, с которым вы на грани расставания, в общем-то не возражает, если ты решишь «поискать варианты». Да и Саша симпатичен/чна. Но ты понимаешь, что хочешь выстроить крепкую культуру в компании, не сломать едва зарождающиеся правила этики и не выглядеть в глазах остальных как человек, который злоупотребляет служебным положением. К тому же никто в компании пока не прописал, как быть, если вдруг старший по должности начинает встречаться с кем-то из проектных менеджеров. Быть может ничего такого?
Ты ломаешь голову над несколькими исходами.
Задача на подумать для менеджера
Правильного ответа нет. В таких случаях стоит задать допущения, опиши как бы ты действовал в комментариях к опросу
Постбэк на 14 февраля
Ты недавно зашёл в динамично растущую IT-компанию как деливери-менеджер. Тебе доверили присматривать за процессами и становиться «руководителем руководителей»: под твоим непрямым началом пять продуктовых стримов и команда проектных менеджеров. Компания только формирует культуру ответственности, внедряет карьерные треки и системы развития, и тут на сцену выходишь ты – с новыми идеями и желанием укрепить корпоративные стандарты.
Недавно ты ввел четкий карьерный трек для PM’ов и появились чёткие уровни развития, матрица компетенций и пути например “как из ПМа дорасти до деливери-менеджера” и далее
Самое любопытное, что в компании нет пока жёсткого комплаенса и кодекса поведения: всё на доверии и договорённостях. А по понедельникам люди расслабляются за настолками в офисе. На одном из таких неформальных вечеров к тебе проявляет явные знаки внимания Саша – один из PM’ов. Формально он/она тебе не подчиняется, но твой статус деливери-менеджера всё равно даёт тебе возможность влиять на развитие карьеры Саши: есть же единая система оценки, которую ты помогаешь поддерживать.
Тем временем, у тебя дома всё довольно шатко: партнёр, с которым вы на грани расставания, в общем-то не возражает, если ты решишь «поискать варианты». Да и Саша симпатичен/чна. Но ты понимаешь, что хочешь выстроить крепкую культуру в компании, не сломать едва зарождающиеся правила этики и не выглядеть в глазах остальных как человек, который злоупотребляет служебным положением. К тому же никто в компании пока не прописал, как быть, если вдруг старший по должности начинает встречаться с кем-то из проектных менеджеров. Быть может ничего такого?
Ты ломаешь голову над несколькими исходами.
👀9💅4
Какой вариант подсказывает разум выбрать?
Anonymous Poll
37%
Ты можешь на время свести общение с Сашей к рабочему, пока в компании не появятся формальные правила
22%
Ты можешь прямо обсудить с Сашей все возможные последствия и риски
10%
Ты можешь предупредить своего партнёра о ситуации и дальн. шагах
12%
Ты можешь попросить HR или проектный офис помочь сформулировать и внедрить принципы комплаенса
14%
Ты можешь дать ход симпатии без лишних формальностей, честно объясняя всем вокруг
4%
Твой вариант (напиши в комментариях)
#рецепт
Критерий софтов менеджера: зовут ли вас на пиво после увольнения?
Я рекомендую устанавливать тесные связи с коллегами. Когда меня спросили, какие метрики лучше всего отражают уровень вовлеченности менеджера в команде, я ответил: «Количество приглашений в бар». Да, звучит специфично, но если команда готова общаться с тобой вне офиса, а бывшие коллеги не просто сохраняют ваш контакт, но и делятся корпоративными сплетнями, – значит, ты выстроил отношения не на сухих отчётах и митингах
Если к тебе тянутся люди (даже когда вы уже не в одной компании), то при поиске новой работы или наборе «команды мечты» все двери открыты. А если после ухода никто даже не пишет «Привет, как дела?» – возможно, дело не в Agile, Kanban или project delivery, а в элементарном отсутствии доверия и человеческого контакта
P.S. Поделиcь своей историей: с кем удалось сохранить общение после ухода? И как эти «барные связи» помогли тебе в будущем?
P.P.S. Читатель, если ты мой бывший коллега, то я буду рад приглашению от тебя на пиво, давно не виделись!
Критерий софтов менеджера: зовут ли вас на пиво после увольнения?
Я рекомендую устанавливать тесные связи с коллегами. Когда меня спросили, какие метрики лучше всего отражают уровень вовлеченности менеджера в команде, я ответил: «Количество приглашений в бар». Да, звучит специфично, но если команда готова общаться с тобой вне офиса, а бывшие коллеги не просто сохраняют ваш контакт, но и делятся корпоративными сплетнями, – значит, ты выстроил отношения не на сухих отчётах и митингах
Если к тебе тянутся люди (даже когда вы уже не в одной компании), то при поиске новой работы или наборе «команды мечты» все двери открыты. А если после ухода никто даже не пишет «Привет, как дела?» – возможно, дело не в Agile, Kanban или project delivery, а в элементарном отсутствии доверия и человеческого контакта
P.S. Поделиcь своей историей: с кем удалось сохранить общение после ухода? И как эти «барные связи» помогли тебе в будущем?
P.P.S. Читатель, если ты мой бывший коллега, то я буду рад приглашению от тебя на пиво, давно не виделись!
🍾29👍17💅8
#кейс_стади
Задача на подумать для менеджера
Кейс вызвал некоторую долю негатива, так как я написал его, но не прочекал что нейронки при исправлении грам. ошибок потерли важные тезисы и переформулировали по своему. Буду внимательнее
А еще он вызвал некоторое недоумение и позицию «на работе — только работа, а всё остальное оставляйте за порогом офиса». Но мы же живые люди: невозможно одним щелчком рубильника отрубить часть мозга, которая отвечает за эмоциональные реакции. Поэтому естественно, что в рабочем пространстве могут возникать неприязнь, дружба, романтическое влечение или даже непреодолимое желание покурить с коллегами и заодно обсудить, стоит ли нам нанимать, условно, Катю. Ситуация вполне реальна — я сам с ней столкнулся — и считаю, что это отличный вызов для руководителя, который нужно научиться преодолевать
С одной стороны, всё выглядит щекотливо. С другой, если смотреть через призму ценностей и категорического императива Канта, то всё упрощается
Хочу ли я, чтобы в компании множились «романтические отношения»? Нет, ведь ни мы, ни сотрудники сейчас не настолько зрелы, чтобы спокойно это выдерживать
Хочу ли я, чтобы партнёр вёл себя по отношению ко мне точно так же? Тоже нет: я сторонник честности и прозрачности, а наши проблемы ещё можно починить
Могу ли я пофлиртовать с человеком? Да, вежливо и однозначно без перспективы на что-то большее. Могут ли меня неверно понять? Вполне. Стану ли я повторять это снова? Скорее нет
Поэтому, с моей точки зрения, тут в принципе не было «правильных» вариантов. Важно включиться в выстраивание корпоративной культуры, где станет ясно, что допустимо, а что нет; нам нужны конкретные «правила игры». Если подобный флирт всплывёт снова, стоит привлечь HR и отдельно поговорить с сотрудником, а с партнёром сохранять открытость и тепло: ведь мимолётная симпатия не отменяет сути наших отношений. Правда, некоторые люди предпочитают даже такие нюансы обсуждать друг с другом, и это тоже нормальная практика
Задача на подумать для менеджера
Кейс вызвал некоторую долю негатива, так как я написал его, но не прочекал что нейронки при исправлении грам. ошибок потерли важные тезисы и переформулировали по своему. Буду внимательнее
А еще он вызвал некоторое недоумение и позицию «на работе — только работа, а всё остальное оставляйте за порогом офиса». Но мы же живые люди: невозможно одним щелчком рубильника отрубить часть мозга, которая отвечает за эмоциональные реакции. Поэтому естественно, что в рабочем пространстве могут возникать неприязнь, дружба, романтическое влечение или даже непреодолимое желание покурить с коллегами и заодно обсудить, стоит ли нам нанимать, условно, Катю. Ситуация вполне реальна — я сам с ней столкнулся — и считаю, что это отличный вызов для руководителя, который нужно научиться преодолевать
С одной стороны, всё выглядит щекотливо. С другой, если смотреть через призму ценностей и категорического императива Канта, то всё упрощается
Хочу ли я, чтобы в компании множились «романтические отношения»? Нет, ведь ни мы, ни сотрудники сейчас не настолько зрелы, чтобы спокойно это выдерживать
Хочу ли я, чтобы партнёр вёл себя по отношению ко мне точно так же? Тоже нет: я сторонник честности и прозрачности, а наши проблемы ещё можно починить
Могу ли я пофлиртовать с человеком? Да, вежливо и однозначно без перспективы на что-то большее. Могут ли меня неверно понять? Вполне. Стану ли я повторять это снова? Скорее нет
Поэтому, с моей точки зрения, тут в принципе не было «правильных» вариантов. Важно включиться в выстраивание корпоративной культуры, где станет ясно, что допустимо, а что нет; нам нужны конкретные «правила игры». Если подобный флирт всплывёт снова, стоит привлечь HR и отдельно поговорить с сотрудником, а с партнёром сохранять открытость и тепло: ведь мимолётная симпатия не отменяет сути наших отношений. Правда, некоторые люди предпочитают даже такие нюансы обсуждать друг с другом, и это тоже нормальная практика
👍15💩8🤡1
#рецепт
Систематизация поиска работы. Часть 2
Привет, читатель! Если ты хоть раз искал работу или сейчас в афиге с рынка и HH, то наверняка замечал, как сложно держать в голове всё: куда откликнулся, какую компанию выбираешь, а ещё какие вопросы всплывают на собеседовании. Это почти как пытаться вспомнить, куда положил ключи — только в два раза запутаннее.
Я не раз ломал голову над этим, пока не собрал всю инфу в одну табличку. Раньше она была «небольшой» заметкой, а теперь я полностью переработал шаблон: добавил подробные гайды, лайфхаки и советы. В этом инструменте ты найдёшь не только список компаний и этапы откликов, но и рекомендации по самопрезентации. Там подробно описано, что стоит сделать до каждого этапа (подготовка резюме, исследование компаний), какие шаги предпринять во время собеседования (как выделиться, не потеряться) и что делать после встречи (анализ, обратная связь, последующие действия).
Улучшенная версия с гидами и дополнительными инструментами:
https://docs.google.com/spreadsheets/d/1_HHygL-BfZGbhAgLWa4ivyR-lYTMAD9VPi7cO_BxjOM/edit?gid=877236755#gid=877236755
Оригинальный шаблон:
https://docs.google.com/spreadsheets/d/1C_Q-JwlAnBzN7joxXXkYfx5r9InTWcYWFuxA42hR0i8/edit?usp=sharing
Не стесняйся копировать, настраивать и делиться этим инструментом. А если вдруг список компаний станет таким длинным, что ты начнёшь сомневаться, не отправил ли уже резюме на кого-то — знай: даже я иногда теряюсь в собственных таблицах! 😉
Систематизация поиска работы. Часть 2
Привет, читатель! Если ты хоть раз искал работу или сейчас в афиге с рынка и HH, то наверняка замечал, как сложно держать в голове всё: куда откликнулся, какую компанию выбираешь, а ещё какие вопросы всплывают на собеседовании. Это почти как пытаться вспомнить, куда положил ключи — только в два раза запутаннее.
Я не раз ломал голову над этим, пока не собрал всю инфу в одну табличку. Раньше она была «небольшой» заметкой, а теперь я полностью переработал шаблон: добавил подробные гайды, лайфхаки и советы. В этом инструменте ты найдёшь не только список компаний и этапы откликов, но и рекомендации по самопрезентации. Там подробно описано, что стоит сделать до каждого этапа (подготовка резюме, исследование компаний), какие шаги предпринять во время собеседования (как выделиться, не потеряться) и что делать после встречи (анализ, обратная связь, последующие действия).
Улучшенная версия с гидами и дополнительными инструментами:
https://docs.google.com/spreadsheets/d/1_HHygL-BfZGbhAgLWa4ivyR-lYTMAD9VPi7cO_BxjOM/edit?gid=877236755#gid=877236755
Оригинальный шаблон:
https://docs.google.com/spreadsheets/d/1C_Q-JwlAnBzN7joxXXkYfx5r9InTWcYWFuxA42hR0i8/edit?usp=sharing
Не стесняйся копировать, настраивать и делиться этим инструментом. А если вдруг список компаний станет таким длинным, что ты начнёшь сомневаться, не отправил ли уже резюме на кого-то — знай: даже я иногда теряюсь в собственных таблицах! 😉
🔥34👍7🤯3🤡2
#кейс_стади
Задача на подумать для менеджера
Правильного ответа нет. В таких случаях стоит задать допущения, опиши как бы ты действовал в комментариях к опросу
Твоя роль
Ты — проджект-менеджер в аутсорсинговой студии, ведешь коммерчески значимый проект по телемедицине, где изначально обещали полную занятость выделенной команды.
Контекст
Студия не слишком большая, но амбициозная: берется за сложные IT-разработки под разные ниши. У вас сейчас несколько средних проектов, но именно телемедицинский — самый прибыльный и долгосрочный. Фаундер компании, Виктор, всегда охотится за новыми контрактами и верит, что можно «усидеть на двух стульях»: взять еще госзаказ в энергетике, без предоплаты, но якобы с «большим статусом» и обещанным «широким горизонтом» (а по факту — пока одна лишь идея и знакомый заказчик).
Проблема
Из-за желания Виктора ввязаться в этот энергетический гостендер мою команду решили периодически «дергать» на новый проект. Однако вы договаривались, что люди будут погружены на 100% в телемедицину, да и заказчик крайне щепетилен к срокам и качеству. Если вы распылите ресурс на два фронта, рискуем завалить оба: телемедицину — по срокам и качеству, госзаказ — по организации и непроясненным ТЗ. Виктор не видит проблемы, а ты опасаешься, что в итоге «не съем и не надкушу».
Твоя цель
Сохранить фокус команды на телемедицине, не потеряв ключевого заказчика и годовой стабильный доход, но при этом не вступать в открытый конфликт с Виктором и не создать внутри команды хаос и демотивацию.
Другие действующие лица
- Виктор (фаундер): видит в гостендере репутационные и потенциально финансовые выгоды, уверен, что «мы все успеем и от этого только выиграем».
- Аккаунт-менеджер: пытается всем угодить, подыгрывает фаундеру, но при этом передает мне тревожные сигналы; понимает, что конфликта не избежать.
- Команда разработчиков: беспокоится о своей загрузке и качестве работ, не хочет работать без четкого ТЗ в новом проекте, да еще и одновременно с телемедициной.
Ситуация очевидно патовая, и легкого решения здесь нет. Можно либо прогнуть фаундера, рискуя собственной позицией, либо молчать и наблюдать, как тонет твой ключевой проект вместе со всей командой
Задача на подумать для менеджера
Правильного ответа нет. В таких случаях стоит задать допущения, опиши как бы ты действовал в комментариях к опросу
Твоя роль
Ты — проджект-менеджер в аутсорсинговой студии, ведешь коммерчески значимый проект по телемедицине, где изначально обещали полную занятость выделенной команды.
Контекст
Студия не слишком большая, но амбициозная: берется за сложные IT-разработки под разные ниши. У вас сейчас несколько средних проектов, но именно телемедицинский — самый прибыльный и долгосрочный. Фаундер компании, Виктор, всегда охотится за новыми контрактами и верит, что можно «усидеть на двух стульях»: взять еще госзаказ в энергетике, без предоплаты, но якобы с «большим статусом» и обещанным «широким горизонтом» (а по факту — пока одна лишь идея и знакомый заказчик).
Проблема
Из-за желания Виктора ввязаться в этот энергетический гостендер мою команду решили периодически «дергать» на новый проект. Однако вы договаривались, что люди будут погружены на 100% в телемедицину, да и заказчик крайне щепетилен к срокам и качеству. Если вы распылите ресурс на два фронта, рискуем завалить оба: телемедицину — по срокам и качеству, госзаказ — по организации и непроясненным ТЗ. Виктор не видит проблемы, а ты опасаешься, что в итоге «не съем и не надкушу».
Твоя цель
Сохранить фокус команды на телемедицине, не потеряв ключевого заказчика и годовой стабильный доход, но при этом не вступать в открытый конфликт с Виктором и не создать внутри команды хаос и демотивацию.
Другие действующие лица
- Виктор (фаундер): видит в гостендере репутационные и потенциально финансовые выгоды, уверен, что «мы все успеем и от этого только выиграем».
- Аккаунт-менеджер: пытается всем угодить, подыгрывает фаундеру, но при этом передает мне тревожные сигналы; понимает, что конфликта не избежать.
- Команда разработчиков: беспокоится о своей загрузке и качестве работ, не хочет работать без четкого ТЗ в новом проекте, да еще и одновременно с телемедициной.
Ситуация очевидно патовая, и легкого решения здесь нет. Можно либо прогнуть фаундера, рискуя собственной позицией, либо молчать и наблюдать, как тонет твой ключевой проект вместе со всей командой
🔥8👍3🎉1💩1
Как будешь действовать в такой ситуации?
Anonymous Poll
9%
Следовать указаниям Виктора, документируя риски и открыто уведомляя заказчика о переносах и причинах
18%
Жесткая позиция, что без полноценной занятости разработчиков проект сорвется
39%
Выделить фиксированные «слоты» под новый проект в команде и прибегнуть к shared team
1%
Позволить команде самостоятельно вести «гос»-часть, лишь поставляя общие рамки
29%
Предложить нанять отдельного PM для энергетики, сохранив мою команду под телемедицину
4%
Твой вариант (напиши в комментариях)
👍3🔥3💩2👏1
#кейс_стади
Задача на подумать для менеджера
Правильный вариант первый - Следовать указаниям Виктора. Но с хорошим управлением ожиданиями. Ниже напишу почему
Если смотреть через призму PAEL, то фаундер здесь классический E — предприниматель, живущий перспективами и идеями «взять всё и сразу», а менеджер (ты) — больше P, человек результата и четкости. Многие в комментариях говорили, что «это вообще не кейс, ведь очевидно, что менеджер должен был выстроить процесс планирования, и шеринг ресурсов в аутсорсе — нормальная практика». Но важно учитывать, что у любой бюрократии есть косты, и не всегда целесообразно делать громоздкий процесс в маленькой студии. Особенно когда «A»-компонента (процедуры, формальности) может быть лишь в меру — ведь каждая дополнительная регламентация отнимает время и деньги.
Ситуация классическая: E хочет всё и сразу, и видит это как гениальный прорыв, а P считает, что мы можем в полной мере сделать только один проект, чтобы его не загубить. Отсюда основная задача — выровнять ожидания и договориться, ради чего мы вообще рискуем. Телемедицина — флагман и наша кормилица, там dedicated-команда на полную загрузку, плюс долгий контракт. А энергетика пока выглядит как возможность «прокачать портфель» и повысить статус компании, но без четкого ТЗ и непонятными рисками.
Значит, нужно вернуться к «стратегии» или, если никакой формальной нет, хотя бы к здравому смыслу. Задать себе вопрос: в ближайшие полгода важнее доходность и кэшфлоу или репутационные/имиджевые кейсы? Ресурсы не обязательно просчитывать детально, но хотя бы «прикинуть на пальцах», насколько может пострадать телемед и чего мы недосчитаемся, если вдруг увлечемся энергетикой. И точно так же обозначить, сколько всего «неизвестных» в новом проекте и насколько они могут потянуть бюджет и время.
Полномочия менеджера заканчиваются там, где речь идет о выборе портфеля. Он не может решить за всю компанию, но должен подсветить риски, предложить варианты и поуправлять ожиданиями. Если фаундер, в роли «E», всё-таки захочет ввязаться, это его решение. Задача менеджера — зафиксировать согласованные риски, сроки, потери и не дать создать иллюзию, будто мы все потянем одной и той же командой, да еще и без ущерба флагману
P.S. Если не видели старенькое это, стоит увидеть https://www.youtube.com/watch?v=EH_3ukkNuwg
Задача на подумать для менеджера
Правильный вариант первый - Следовать указаниям Виктора. Но с хорошим управлением ожиданиями. Ниже напишу почему
Если смотреть через призму PAEL, то фаундер здесь классический E — предприниматель, живущий перспективами и идеями «взять всё и сразу», а менеджер (ты) — больше P, человек результата и четкости. Многие в комментариях говорили, что «это вообще не кейс, ведь очевидно, что менеджер должен был выстроить процесс планирования, и шеринг ресурсов в аутсорсе — нормальная практика». Но важно учитывать, что у любой бюрократии есть косты, и не всегда целесообразно делать громоздкий процесс в маленькой студии. Особенно когда «A»-компонента (процедуры, формальности) может быть лишь в меру — ведь каждая дополнительная регламентация отнимает время и деньги.
Ситуация классическая: E хочет всё и сразу, и видит это как гениальный прорыв, а P считает, что мы можем в полной мере сделать только один проект, чтобы его не загубить. Отсюда основная задача — выровнять ожидания и договориться, ради чего мы вообще рискуем. Телемедицина — флагман и наша кормилица, там dedicated-команда на полную загрузку, плюс долгий контракт. А энергетика пока выглядит как возможность «прокачать портфель» и повысить статус компании, но без четкого ТЗ и непонятными рисками.
Значит, нужно вернуться к «стратегии» или, если никакой формальной нет, хотя бы к здравому смыслу. Задать себе вопрос: в ближайшие полгода важнее доходность и кэшфлоу или репутационные/имиджевые кейсы? Ресурсы не обязательно просчитывать детально, но хотя бы «прикинуть на пальцах», насколько может пострадать телемед и чего мы недосчитаемся, если вдруг увлечемся энергетикой. И точно так же обозначить, сколько всего «неизвестных» в новом проекте и насколько они могут потянуть бюджет и время.
Полномочия менеджера заканчиваются там, где речь идет о выборе портфеля. Он не может решить за всю компанию, но должен подсветить риски, предложить варианты и поуправлять ожиданиями. Если фаундер, в роли «E», всё-таки захочет ввязаться, это его решение. Задача менеджера — зафиксировать согласованные риски, сроки, потери и не дать создать иллюзию, будто мы все потянем одной и той же командой, да еще и без ущерба флагману
P.S. Если не видели старенькое это, стоит увидеть https://www.youtube.com/watch?v=EH_3ukkNuwg
🔥10👍3🤔2💩2👀1
#рецепт
Важные для проектного менеджера понятия технички. Часть 1
Привет, читатель! Я забыл подготовить задачу, поэтому будет другое, но также полезное
В условиях, когда нейросети всё активнее влияют на нашу жизнь, становится пользительно иметь хотя бы поверхностное представление о том, что происходит вокруг. Знать эти концепции — значит быстрее ориентироваться в том, с чем работает твоя команда, и уметь сложить в голове целостную картину IT-систем. Представь, что ты начинающий PM без глубокого техбэкграунда, а опытный наставник объясняет всё простыми словами, по принципам Фейнмана. Ниже приведён перечень тем, которые стоит поочерёдно разбирать с помощью GPT — по одной теме в отдельном чате. Вот список, который поможет тебе быстро разобраться в сложной терминологии на уровне энтерпрайзных систем, а не университетских лекций по C или Python
1) Что происходит, когда данные передаются по сети?
– Модель OSI (интерфейсы, уровни, преобразование сообщений)
– Модель TCP/IP (протоколы, интерфейсы, маршрутизация)
– Протокол TCP (надежность, установление соединения, контроль ошибок)
– Протокол UDP (скорость, отсутствие подтверждения, неупорядоченность)
– IP-адрес (статический, динамический, адресация)
– MAC-адрес (уникальный физический идентификатор)
– Сетевые порты (идентификация сервисов)
– DNS (разрешение доменных имен)
– Хостинг (серверы, инфраструктура)
2) Что происходит при открытии сайта в браузере?
– URI (схема, путь, параметры, кастомные схемы)
– URL (схема, домен, порт, путь, параметры)
– HTTP (методы, заголовки, параметры, статусная строка)
– HTTPS (SSL/TLS, шифрование, безопасность)
– Браузер (интерпретация, рендеринг)
– HTML (структура, разметка)
– CSS (стили, внешний вид)
– JavaScript (динамика, интерактивность)
– DOM (структура документа)
– Cookies (сессионные данные)
– Кеширование (локальное хранение, ускорение загрузки)
3) Как передаются сообщения в сети интернет?
– REST API (методы, заголовки, параметры, статусная строка)
– SOAP (XML, WSDL, структура обмена)
– GraphQL (запросы, схема, резолверы)
– gRPC (RPC, HTTP/2, бинарный протокол)
– Webhooks (обратные вызовы, события)
– WebSockets (постоянное соединение, двунаправленная связь)
– Пуши (веб и мобильные пуш-уведомления, Server-Sent Events – SSE)
4) Как организуются интеграции между системами в интернете?
– Файловый обмен (форматы, периодичность)
– Общая база данных (совместное использование, консистентность)
– Вызов удалённой процедуры (RPC, прямые вызовы)
– Асинхронный обмен сообщениями (очереди, брокеры)
– Ресурсный стиль (REST) (HTTP, CRUD, JSON)
– RPC-стиль (синхронные вызовы)
– Query-стиль (запросы, получение данных)
– Publisher/Subscriber (подписка, уведомления)
Важные для проектного менеджера понятия технички. Часть 1
Привет, читатель! Я забыл подготовить задачу, поэтому будет другое, но также полезное
В условиях, когда нейросети всё активнее влияют на нашу жизнь, становится пользительно иметь хотя бы поверхностное представление о том, что происходит вокруг. Знать эти концепции — значит быстрее ориентироваться в том, с чем работает твоя команда, и уметь сложить в голове целостную картину IT-систем. Представь, что ты начинающий PM без глубокого техбэкграунда, а опытный наставник объясняет всё простыми словами, по принципам Фейнмана. Ниже приведён перечень тем, которые стоит поочерёдно разбирать с помощью GPT — по одной теме в отдельном чате. Вот список, который поможет тебе быстро разобраться в сложной терминологии на уровне энтерпрайзных систем, а не университетских лекций по C или Python
1) Что происходит, когда данные передаются по сети?
– Модель OSI (интерфейсы, уровни, преобразование сообщений)
– Модель TCP/IP (протоколы, интерфейсы, маршрутизация)
– Протокол TCP (надежность, установление соединения, контроль ошибок)
– Протокол UDP (скорость, отсутствие подтверждения, неупорядоченность)
– IP-адрес (статический, динамический, адресация)
– MAC-адрес (уникальный физический идентификатор)
– Сетевые порты (идентификация сервисов)
– DNS (разрешение доменных имен)
– Хостинг (серверы, инфраструктура)
2) Что происходит при открытии сайта в браузере?
– URI (схема, путь, параметры, кастомные схемы)
– URL (схема, домен, порт, путь, параметры)
– HTTP (методы, заголовки, параметры, статусная строка)
– HTTPS (SSL/TLS, шифрование, безопасность)
– Браузер (интерпретация, рендеринг)
– HTML (структура, разметка)
– CSS (стили, внешний вид)
– JavaScript (динамика, интерактивность)
– DOM (структура документа)
– Cookies (сессионные данные)
– Кеширование (локальное хранение, ускорение загрузки)
3) Как передаются сообщения в сети интернет?
– REST API (методы, заголовки, параметры, статусная строка)
– SOAP (XML, WSDL, структура обмена)
– GraphQL (запросы, схема, резолверы)
– gRPC (RPC, HTTP/2, бинарный протокол)
– Webhooks (обратные вызовы, события)
– WebSockets (постоянное соединение, двунаправленная связь)
– Пуши (веб и мобильные пуш-уведомления, Server-Sent Events – SSE)
4) Как организуются интеграции между системами в интернете?
– Файловый обмен (форматы, периодичность)
– Общая база данных (совместное использование, консистентность)
– Вызов удалённой процедуры (RPC, прямые вызовы)
– Асинхронный обмен сообщениями (очереди, брокеры)
– Ресурсный стиль (REST) (HTTP, CRUD, JSON)
– RPC-стиль (синхронные вызовы)
– Query-стиль (запросы, получение данных)
– Publisher/Subscriber (подписка, уведомления)
👍23🔥11💩2
#рецепт
Важные для проектного менеджера понятия технички. Часть 2
5) Как данные хранятся и обрабатываются?
– Таблицы (строки, столбцы, структура)
– Реляционные и нереляционные БД (таблицы vs документы, кортежи vs key-value, связи и ключи vs графы)
– Нормальные формы (структурирование, целостность)
– SQL-запросы (выборка, вставка, создание, обновление и параметры)
– Индексы (ускорение поиска)
– Транзакции (атомарность, целостность)
– Хранимые процедуры (запрограммированные операции)
– Вьюшки (логические представления)
6) Как работает отправка сообщений без немедленного ответа?
– Очередь сообщений (последовательность, асинхронность)
– Брокер сообщений (маршрутизация, управление очередями)
– AMQP (RabbitMQ) (протокол, гарантированная доставка)
– Kafka (потоковая передача, масштабируемость)
– Redis (Pub/Sub, in-memory, высокая скорость)
7) Как разные части систем организуют в структуру?
– Клиент-серверная архитектура (клиент, сервер, запрос-ответ)
– Монолитная архитектура (единое приложение, централизованность)
– Микросервисная архитектура (независимые сервисы, масштабируемость)
– N-tier архитектура (слоистость: данные, бизнес-логика, представление)
– Энтерпрайз архитектура (корпоративная интеграция, масштаб)
– Serverless архитектура (FaaS, облачные функции, автоматическое масштабирование)
– Фронтенд архитектура (MVC, MVVM, MVP)
– Стили архитектуры (Layered, Event-driven, Microkernel, Service-Oriented, Space-based, Pipe-and-Filter, Broker, Peer-to-Peer)
– Паттерны (API Gateway, BFF, Circuit Breaker, Saga, CQRS и т.д.)
8) Как обеспечивается безопасность?
– Аутентификация (подтверждение, идентификация, токены, сессии)
– 3rd party (аутентификация, токены, типы)
– Авторизация (права доступа, контроль)
– Шифрование (криптография, защита данных)
– SSL/TLS (шифрование трафика, сертификаты)
– Фаерволы (фильтрация, контроль доступа)
– VPN (защищённое соединение, туннелирование)
– IDS/IPS (обнаружение, предотвращение вторжений)
– Двухфакторная аутентификация (otp, totp)
– SSO (единый вход)
– SAML (протокол обмена аутентификационными данными)
– Модели управления доступами (permission shema, ACS)
Важные для проектного менеджера понятия технички. Часть 2
5) Как данные хранятся и обрабатываются?
– Таблицы (строки, столбцы, структура)
– Реляционные и нереляционные БД (таблицы vs документы, кортежи vs key-value, связи и ключи vs графы)
– Нормальные формы (структурирование, целостность)
– SQL-запросы (выборка, вставка, создание, обновление и параметры)
– Индексы (ускорение поиска)
– Транзакции (атомарность, целостность)
– Хранимые процедуры (запрограммированные операции)
– Вьюшки (логические представления)
6) Как работает отправка сообщений без немедленного ответа?
– Очередь сообщений (последовательность, асинхронность)
– Брокер сообщений (маршрутизация, управление очередями)
– AMQP (RabbitMQ) (протокол, гарантированная доставка)
– Kafka (потоковая передача, масштабируемость)
– Redis (Pub/Sub, in-memory, высокая скорость)
7) Как разные части систем организуют в структуру?
– Клиент-серверная архитектура (клиент, сервер, запрос-ответ)
– Монолитная архитектура (единое приложение, централизованность)
– Микросервисная архитектура (независимые сервисы, масштабируемость)
– N-tier архитектура (слоистость: данные, бизнес-логика, представление)
– Энтерпрайз архитектура (корпоративная интеграция, масштаб)
– Serverless архитектура (FaaS, облачные функции, автоматическое масштабирование)
– Фронтенд архитектура (MVC, MVVM, MVP)
– Стили архитектуры (Layered, Event-driven, Microkernel, Service-Oriented, Space-based, Pipe-and-Filter, Broker, Peer-to-Peer)
– Паттерны (API Gateway, BFF, Circuit Breaker, Saga, CQRS и т.д.)
8) Как обеспечивается безопасность?
– Аутентификация (подтверждение, идентификация, токены, сессии)
– 3rd party (аутентификация, токены, типы)
– Авторизация (права доступа, контроль)
– Шифрование (криптография, защита данных)
– SSL/TLS (шифрование трафика, сертификаты)
– Фаерволы (фильтрация, контроль доступа)
– VPN (защищённое соединение, туннелирование)
– IDS/IPS (обнаружение, предотвращение вторжений)
– Двухфакторная аутентификация (otp, totp)
– SSO (единый вход)
– SAML (протокол обмена аутентификационными данными)
– Модели управления доступами (permission shema, ACS)
🔥15💩2
#рецепт
Важные для проектного менеджера понятия технички. Часть 3
9) Какие практики автоматизируют ручные операции в IT?
– VCS (ветки, коммиты, мерж, реквесты)
– CI/CD (сборка, тестирование, деплой, Jenkins)
– Контейнеризация (Docker, изоляция)
– Окружения (development, staging, production)
– Управление секретами
– IaC (Infrastructure as Code) (автоматизированное развертывание инфраструктуры, Terraform, CloudFormation)
– Мониторинг и логирование (сбор метрик, Prometheus, Grafana, ELK)
– Управление конфигурацией (единое управление настройками, Ansible, Puppet, Chef)
10) Как обеспечивается масштабирование и высокая производительность?
– Горизонтальное масштабирование (добавление серверов)
– Вертикальное масштабирование (расширение ресурсов)
– Репликация (копирование данных, отказоустойчивость)
– Балансировка нагрузки (NGINX, распределение запросов)
– Кэширование (Redis, Memcached, ускорение доступа)
– Обработка отказов (резервирование, восстановление)
– Load testing (оценка производительности)
11) Как организована IT-инфраструктура и поддержка сервисов?
– Мониторинг (отслеживание состояния, метрики)
– Алертинг (системы оповещений)
– Резервное копирование (backup, периодичность)
– Бэкапы (архивирование, восстановление)
– Облачные сервисы (IaaS, PaaS, SaaS)
– CDN (быстрая доставка контента)
– DNS-серверы (управление доменами)
Теория – это хорошо, но одного прочтения мало. Практика должна закреплять знания. Вот три варианта, как можно это делать:
1) Сократовский диалог с GPT – пусть по каждой теме GPT задаёт вопросы, а ты отвечаешь, чтобы глубже понять суть.
2) Рисуй схемы – составь, например, компонентную диаграмму интернет-магазина или ER-диаграмму для своей базы данных. Используй GPT для визуализации – попробуй GPTs, например по ссылке https://chatgpt.com/g/g-B1Bfoq5qh-uml-diagram-expert, который реально помогает отрисовывать диаграммы.
3) Пиши свой micro-SaaS.http://cursor.ai или аналоги вполне могут тебе помочь
P.S. Сейчас такое время, когда я смог за один вечер с GPT сложить чёткое понимание OSI и TCP/IP, вместо того чтобы валяться над 700-страничной книгой по компьютерным сетям как на ИВТ в ВУЗ-е
P.P.S. Вот также сборная солянка от одного хорошего человека в одном документе https://docs.google.com/document/d/1CzTkVPdiC6-0oit3yoGJlD2AM0xzGJD7pO08PIUNg1w/edit?tab=t.0#heading=h.8wrxytxwlauq и отличная книга https://www.litres.ru/book/aleks-suy/system-design-podgotovka-k-slozhnomu-intervu-67193183/
Важные для проектного менеджера понятия технички. Часть 3
9) Какие практики автоматизируют ручные операции в IT?
– VCS (ветки, коммиты, мерж, реквесты)
– CI/CD (сборка, тестирование, деплой, Jenkins)
– Контейнеризация (Docker, изоляция)
– Окружения (development, staging, production)
– Управление секретами
– IaC (Infrastructure as Code) (автоматизированное развертывание инфраструктуры, Terraform, CloudFormation)
– Мониторинг и логирование (сбор метрик, Prometheus, Grafana, ELK)
– Управление конфигурацией (единое управление настройками, Ansible, Puppet, Chef)
10) Как обеспечивается масштабирование и высокая производительность?
– Горизонтальное масштабирование (добавление серверов)
– Вертикальное масштабирование (расширение ресурсов)
– Репликация (копирование данных, отказоустойчивость)
– Балансировка нагрузки (NGINX, распределение запросов)
– Кэширование (Redis, Memcached, ускорение доступа)
– Обработка отказов (резервирование, восстановление)
– Load testing (оценка производительности)
11) Как организована IT-инфраструктура и поддержка сервисов?
– Мониторинг (отслеживание состояния, метрики)
– Алертинг (системы оповещений)
– Резервное копирование (backup, периодичность)
– Бэкапы (архивирование, восстановление)
– Облачные сервисы (IaaS, PaaS, SaaS)
– CDN (быстрая доставка контента)
– DNS-серверы (управление доменами)
Теория – это хорошо, но одного прочтения мало. Практика должна закреплять знания. Вот три варианта, как можно это делать:
1) Сократовский диалог с GPT – пусть по каждой теме GPT задаёт вопросы, а ты отвечаешь, чтобы глубже понять суть.
2) Рисуй схемы – составь, например, компонентную диаграмму интернет-магазина или ER-диаграмму для своей базы данных. Используй GPT для визуализации – попробуй GPTs, например по ссылке https://chatgpt.com/g/g-B1Bfoq5qh-uml-diagram-expert, который реально помогает отрисовывать диаграммы.
3) Пиши свой micro-SaaS.http://cursor.ai или аналоги вполне могут тебе помочь
P.S. Сейчас такое время, когда я смог за один вечер с GPT сложить чёткое понимание OSI и TCP/IP, вместо того чтобы валяться над 700-страничной книгой по компьютерным сетям как на ИВТ в ВУЗ-е
P.P.S. Вот также сборная солянка от одного хорошего человека в одном документе https://docs.google.com/document/d/1CzTkVPdiC6-0oit3yoGJlD2AM0xzGJD7pO08PIUNg1w/edit?tab=t.0#heading=h.8wrxytxwlauq и отличная книга https://www.litres.ru/book/aleks-suy/system-design-podgotovka-k-slozhnomu-intervu-67193183/
🔥15👍13💩2
#кейс_стади
Задача на подумать для менеджера
Правильного ответа нет. В таких случаях стоит задать допущения, опиши как бы ты действовал в комментариях к опросу.
Ты — новый скрам-мастер в B2B-продуктовой компании, которая разрабатывает SaaS-решение для автоматизации складского учета. Это твоя первая серьезная работа, ты вдохновлен идеями Agile и готов помогать команде работать эффективнее.
Но очень быстро ты понимаешь, что скрам в команде есть только номинально.
— В спринтах хаос: никто не может сказать, какие задачи точно готовы, а какие застряли.
— Все называют PBR “грумингами”, но их никто не любит, потому что “они для джунов, а тут все и так во всем разбираются”.
— Демо проходят, но в них смысла нет: клиенты редко приходят, а внутренние стейкхолдеры устали от багов и недоделанных фич.
— Ретроспективы собирают одни и те же проблемы, но никто не хочет реально их решать, потому что “так исторически сложилось”.
Ты пытаешься вникнуть, но тут случается катастрофа.
Крупный клиент, который приносит 30% выручки, внезапно присылает письмо: “Ваш сервис не позволяет нам добавить новые SKU, бизнес встал. Если не решите за 24 часа, мы уходим.”
Ты поднимаешь команду, но начинается шоу "это не моя проблема":
— Разработчики: “Это на стороне бэкенда, фронт тут ни при чем.”
— Бэкенд: “Это не у нас, данные от контрагентов пришли в сломанном формате, пусть продукт разбирается.”
— Продукт: “Я не знаю, что тут сломалось, спросите тестировщиков.”
— Тестировщики: “А нам никто не говорил, что это критично, мы не приоритетили этот сценарий.”
— Тимлид: “Ну да, баги бывают, но что вы от меня хотите?”
— CTO: не отвечает на сообщения, видимо, опять на встречах с инвесторами.
А тебе пишут из продаж:
“Ну что, клиент уже нервничает, что сказать? Что делаете?”
И вот ты, скрам-мастер без технического бэкграунда, без авторитета, без реальной власти, но с дедлайном в 24 часа, стоишь посреди хаоса и должен как-то разрулить это.
Как будешь действовать?
P.S Картинка из старого новостного сюжета про то как вокруг тушат пожар, а рыболов невозмутимо удит
Задача на подумать для менеджера
Правильного ответа нет. В таких случаях стоит задать допущения, опиши как бы ты действовал в комментариях к опросу.
Ты — новый скрам-мастер в B2B-продуктовой компании, которая разрабатывает SaaS-решение для автоматизации складского учета. Это твоя первая серьезная работа, ты вдохновлен идеями Agile и готов помогать команде работать эффективнее.
Но очень быстро ты понимаешь, что скрам в команде есть только номинально.
— В спринтах хаос: никто не может сказать, какие задачи точно готовы, а какие застряли.
— Все называют PBR “грумингами”, но их никто не любит, потому что “они для джунов, а тут все и так во всем разбираются”.
— Демо проходят, но в них смысла нет: клиенты редко приходят, а внутренние стейкхолдеры устали от багов и недоделанных фич.
— Ретроспективы собирают одни и те же проблемы, но никто не хочет реально их решать, потому что “так исторически сложилось”.
Ты пытаешься вникнуть, но тут случается катастрофа.
Крупный клиент, который приносит 30% выручки, внезапно присылает письмо: “Ваш сервис не позволяет нам добавить новые SKU, бизнес встал. Если не решите за 24 часа, мы уходим.”
Ты поднимаешь команду, но начинается шоу "это не моя проблема":
— Разработчики: “Это на стороне бэкенда, фронт тут ни при чем.”
— Бэкенд: “Это не у нас, данные от контрагентов пришли в сломанном формате, пусть продукт разбирается.”
— Продукт: “Я не знаю, что тут сломалось, спросите тестировщиков.”
— Тестировщики: “А нам никто не говорил, что это критично, мы не приоритетили этот сценарий.”
— Тимлид: “Ну да, баги бывают, но что вы от меня хотите?”
— CTO: не отвечает на сообщения, видимо, опять на встречах с инвесторами.
А тебе пишут из продаж:
“Ну что, клиент уже нервничает, что сказать? Что делаете?”
И вот ты, скрам-мастер без технического бэкграунда, без авторитета, без реальной власти, но с дедлайном в 24 часа, стоишь посреди хаоса и должен как-то разрулить это.
Как будешь действовать?
P.S Картинка из старого новостного сюжета про то как вокруг тушат пожар, а рыболов невозмутимо удит
🔥12🌚1
#мнение
Один из десятков концептов мотивации
Здравствуй, мотивированный профессионал – читатель!
За последние годы я столкнулся с множеством подходов: психопрофилирование, мотивационные пирамиды и методики вроде DICS и подходы Герчикова. Все они обещают понимание, просветление и простоту, но часто оказываются поверхностными
Мои наблюдения показали, что айтишники – настоящие ремесленники. Мы ценим возможность работать автономно, видеть рост своих навыков и иметь понятную цель, а не просто "работу в стол"
Ознакомившись с выдержками и статьями по мотивационным идеям Дэниела Пинка, я понял, что принципы автономии, стремления к мастерству и ощущения цели полностью совпадают с моими взглядами. Я не читал всю книгу «Драйв» – для формирования мнения мне достаточно было материалов, которые я изучал через статьи и даже прогнал через GPT Structured Output с reasoning
На практике я применяю эти идеи, предоставляя команде возможность проявлять инициативу, экспериментировать и развиваться. Такой подход помогает сохранить креативность и одновременно двигаться к конкретной цели
Однако абсолютная автономия без четких рамок не всегда работает. В одном из проектов был сотрудник, которого мы условно прозвали «кавасаки». В отличие от тех, кто жаждет свободы и развития, ему было всё равно, что происходит с его задачами. Он требовал лишь, чтобы техническое задание было четко прописано – дал оценку, и дальше его отстраняли от процесса до завершения работы. Он не интересовался общением с командой, избегал развития, отказывался включать камеру на встречах, чтобы его не запомнили. Такой подход не только нарушал коллективную динамику, но и подрывал общий настрой команды. Его формальное отношение к работе показало, что для некоторых людей мотивация 3.0 вовсе не актуальна – им достаточно лишь минимальных требований
Кстати, мы сравнили наши взгляды по этой теме с еще одним Артёмом из канала Плохой Project. Мы с ним написали каждый свой пост на эту тему, и оказалось что хоть и есть общее во взглядах, но многое и разнится
Один из десятков концептов мотивации
Здравствуй, мотивированный профессионал – читатель!
За последние годы я столкнулся с множеством подходов: психопрофилирование, мотивационные пирамиды и методики вроде DICS и подходы Герчикова. Все они обещают понимание, просветление и простоту, но часто оказываются поверхностными
Мои наблюдения показали, что айтишники – настоящие ремесленники. Мы ценим возможность работать автономно, видеть рост своих навыков и иметь понятную цель, а не просто "работу в стол"
Ознакомившись с выдержками и статьями по мотивационным идеям Дэниела Пинка, я понял, что принципы автономии, стремления к мастерству и ощущения цели полностью совпадают с моими взглядами. Я не читал всю книгу «Драйв» – для формирования мнения мне достаточно было материалов, которые я изучал через статьи и даже прогнал через GPT Structured Output с reasoning
На практике я применяю эти идеи, предоставляя команде возможность проявлять инициативу, экспериментировать и развиваться. Такой подход помогает сохранить креативность и одновременно двигаться к конкретной цели
Однако абсолютная автономия без четких рамок не всегда работает. В одном из проектов был сотрудник, которого мы условно прозвали «кавасаки». В отличие от тех, кто жаждет свободы и развития, ему было всё равно, что происходит с его задачами. Он требовал лишь, чтобы техническое задание было четко прописано – дал оценку, и дальше его отстраняли от процесса до завершения работы. Он не интересовался общением с командой, избегал развития, отказывался включать камеру на встречах, чтобы его не запомнили. Такой подход не только нарушал коллективную динамику, но и подрывал общий настрой команды. Его формальное отношение к работе показало, что для некоторых людей мотивация 3.0 вовсе не актуальна – им достаточно лишь минимальных требований
Кстати, мы сравнили наши взгляды по этой теме с еще одним Артёмом из канала Плохой Project. Мы с ним написали каждый свой пост на эту тему, и оказалось что хоть и есть общее во взглядах, но многое и разнится
👍8🤡4🔥3👏1💅1