В целом-то тема интересная. Нужно уметь вплетать сервые и неинтересные задачи оптимизации в волшебную и захватывающую череду задач по разработке новых фичей. Но... удалось ли это?
В статье поднят важный вопрос: как совместить оптимизацию ресурсов с разработкой? Командом нужно было внести оптимизацию в планы, скорректировать бэклоги. Всё это означает ровно то, что раньше команды никак не закладывали обслуживание техдолга, по крайней мере на постоянной основе. Обратная связь по итогам активности - это круто. Но сколько команд стали стали реально закладывать работы по оптимизации в свои спринты? И появилась ли общая тенденция по компании к замедлению роста потребления ресурсов?
В том виде, как рассказывается в статье, это похоже на советскую методику субботников. Год мы бросаем окурки куда попало - а потом весь завод выходит на субботник. Приезжает партийная делегация, делается фото для Комсомольской правды - и всё возвращается на круги своя.
Так с ходу я бы посмотрел в сторону другой концепции. Сначала поработать предметно с 3-4 проектами. Внедрить там "лучшие инженерные практики". А потом анонсировать такой вот "месячник оптимизации", провести стартовый митос со спикерами от этих команд. И дальше по мотивам ретроспективы заниматься внедрением хорошо зарекомендовавших себя подходов в максимальное число команд. Будь то какой-то внутренний гайд или ещё что-то.
Энивей, продвигать оптимизацию в компании лучше, чем не продвигать. Будет интересно почитать про следующую активность!
Вы говорите про четыре проекта, а опыт индустрии - это "сто тысяч миллионов" проектов. Означает ли это, что опыт индустрии однозначно подойдёт конкретно вашему проекту? Нет. Но ваш личный опыт совершенно точно не перечёркивает опыт индустрии. Т.к. в её масштабах это отклонение - это даже не песчинка на берегу океана.
Но в целом соглашусь со мнением, высказанным выше. Взгляд на менеджмент немного отдаёт нафталином.
Тут всё в кучу. Думаю, это и является причиной выгорания. Когда ты "и жнец, и швец" в рамках ЛЮБОЙ роли, ты выгоришь. Точка.
Давайте попробуем разобраться и навести порядок.
Сначала поговорим про скрам. Считать скрам-мастера сугубо "модератором митингов" и говорить, что "это чаще всего кто-то из исполнителей" - это уже маленечко выстрел себе в ногу. СМ может и не участвовать на митингах, например. А ещё он помогает идентифицировать и устранять преграды, предлагает улучшения процессов, работает с обратной связью внутри команды. Важно понимать, что настоящего скрама без СМ не бывает. А значит если команда работает по всамделашнему скраму, то "функции СМ" не обязаны прилипать к тимлиду. А в компаниях, где больше 2-3 проектов, это и вовсе маловероятно.
Теперь конкретно о тимлидах в скраме. Да, такой роли там не описано. Но там и роли CEO компании нет, и бухгалтера нет, и уборщицы. Это означает лишь то, что для тимлида скрам не прописывает каких-то конкретных полномочий или ответственности.
Должен ли тимлид быть архитектором, тестировщиком, кем там угодно ещё? Это уже вопрос организации работы внутри компании. И тут давайте сделаем отсылку к структуре компании. У вас может быть всего один продукт - тогда одна команда и есть вся компания. У вас может быть аутсорс, где работают сотни человек на десятках проектов. Очевидно, что это будет влиять на наполнение роли тимлида. Я не буду углубляться в разделение обязанностей между тимлидом и эйчаром, что является довольно частым случаем, а лушче скажу, что сам подразумеваю под тимлидом.
Для меня тимлид - это прежде всего техлид. Человек, отвечающий за развитие основной технической компетенции своих подопечных (которые строго говоря не обязательно его подчинённые). Техническое совершенство продукта за авторством команды в этом случае - производная. Тимлид это не ультра-сеньор с кучкой вечных джунов за спиной. Это ревьер и ментор. Сильный тимлид растит специалистов. Он может, но не обязан участвовать непосредственно в разработке, построении архитектуры. Что бы он ни делал, его верхреуровневая цель заключается в том, чтобы научить подопечных делать это самим.
Если подытожить, то роль "Тимлид" в описании вакансии на сегодня столь же туманна, как и "Менеджер". Что за этим скрывается - загадка. Заранее задать все вопросы и чётко обозначить рамки - это снизить вероятность выгорания.
Поисковые движки же не имеют контрактов и лицензий вообще со всеми. Я могу ввести поисковый запрос, мне в выдаче будут результаты с таких ресурсов вперемешку с проплаченными позициями. Т.е. поискових демонстрирует изображение со стока и берёт бабло с заказчика рекламы. Такое же косвенное коммерческое использования, как и в случае с ИИ.
Только в случае с ИИ ещё и доказать сложнее. Если поисковик по конкретному запросу показал конкретное изображение, то как тот же Гетти докажет, что ИИ движок каким-то образом использует изображения с сайта при генерации новых?
Чиновники и делегирование им части прав (вместе с ответственностью) нужны в т.ч. и для упрощения принятия решений. В Париже проживает 2 миллиона человек. Чтобы решить, нужны ли городу 15 тысяч электросамокатов нужно опросить 2 миллиона человек? Окей, граждан Франции с избирательным правом там меньше, но всё же. А за чей счёт банкет? Это прокатчики оплатят мероприятие?
А когда выдавали лицензии, тоже опрос проводился? Не одну лицензию - три.
Я поддерживаю демократические ценности, но в этой ситуации это действительно похоже на какой-то популизм и подковёрные игры.
Зерокод - это не уникальная тенденция в IT. Всё вокруг, что входит в нашу повседневную жизнь, упрощается, унифицируется, на каком-то этапе мы уже начинаем считать это нативно понятным. Хотя в момент своего появления этого могли быть чем-то ну очень сложным и не для всех. Например, первые компьютеры и мой ноубтук, с которого я пишу этот коммент.
Я всячески приветствую зекород-решения. Они не убьют энтерпрайз разработку, кастомную разработку и вот это вот всё. А жизнь многих и многих пользователей/заказчиков станет легче.
Ну, это он целей статьи зависит и очерченной ЦА. На серьёзный форум с такой презентахой не пойдёшь. На науч-поп ресурсе для создания "дружелюбного лица компании" - вполне. А раз это корпоративный блог, то какой вариантов ближе, тут вроде как понятно.
В целом ситуация, которая могла случиться не только с архитектором и не только в Сбере. Позиция в компании есть, жёсткого перечня требований нет. Нашёлся кандидат, который устроил внутреннего заказчика вакансии. Виноват ли сам кандидат, что его приняли? Нет. В принципе можно ли оперировать термином "вина"? Только если по итогу этот найм будет признан неудачным.
Так что пока можно пожелать удачи герою статьи и пускай всё получится.
Я скорее вижу позитивный посыл в статье: инвестиции в себя оправдались. Это мотивирует.
Значительная часть комментов, "развенчивающих миф" о прорывном Айфоне, написана по лекалу "Да вот что Эппл, да я вот уже тогда...". Как мне кажется, это скорее попытки возвысить себя и получить свою минуту славы.
На рынке всегда были культовые телефоны - но никогда не было бескомпромиссных телефонов. Минусы и косяки были и будут у всех. Тогда первый Айфон выглядел устройством из другой лиги. Нынешние Айфоны не отличаются настолько от конкурентов, но тогда...
Должны ли мы быть благодарны Джобсу и его команде или же они вынесли приговор рынку мобильных телефонов? Мы ходим в унифицированной одежде, ездим на унифицированных машинах. Те люди, которые сладостно вспоминают N-Gage сейчас ходят по улицам в леопардовых меховых шортах и ездят на ванне с моторчиком? Нет. Ностальгия в комментах и реальный мир всё же разные вещи.
Со своей стороны по практикам коммуникации могу поделиться следующим наблюдением. Менеджер на проекте всегда в меньшинстве (ну, в большинстве случаев). На проекте может быть 1 разработчик или 5, или 10. А менеджер один.
Да, ты не говоришь постоянно <Обращение> + <вводная информация>... и не требуешь квитанцию каждый раз. Но ты всё равно используешь эти приёмы чаще остальных - и этим выбиваешься из общего потока коммуникации. Как менеджер, ты ратуешь за эффективную коммуникацию, учишь всех вести её правильно, по необходимости использовать все вот эти приёмы. Всё равно в твоей речи они будут встречаться чаще, чем у других членов команды.
Для меня мастерство менеджера во много определяется способностью "не набивать оскомину" своим менеджерским подходом и стилем. Когда ты одновременно растворяешься в общем потоке коммуникации и при этом решаешь менеджерские задачи.
>>Таким образом мы выводим главную проблему в коммуникации — потеря данных.
Если мы проводим линию раздела между общением и коммуникацией, то надо в таком случае проводить такую же линию между данными и информацией.
"Потеря данных при коммуникации" это когда в мессенджере не ушло сообщение. Но если при этом собеседник всё понял правильно, то потери информации не произошло. Иными словами, при помощи данных мы передаём информацию. Можно передать данные, но при этом не передать информацию. Передать информацию без передачи данных невозможно.
Это, кстати, проблема менеджмента - данные без информации. В статье правильно подмечена одна из таких ситуаций - повисшие вопросы.
В общем, я бы сформулировал главную проблему чуть иначе: неэффективная передача информации.
В комменте про самый попсовый термин оставлю такой же попсовый коммент - надо быть гибче)
Действительно, ситуации бывают разные. На первый взгляд идти на давно устоявшийся рынок энтерпрайз приложений с MVP бессмысленно. Но обязательно ли сразу стучаться в двери приёмных топ-компаний? Нельзя ли обкатать MVP на игроках попроще? Ну, здорово, когда это возможно.
Соглашусь, что важной пользой от MVP является реальная обратная связь, возможность проведения полевых исследований. Если не на стадии MVP, то когда? Уже слышу шум водопада.
Последнее, что отмечу, это место MVP в роадмапе продукта. MVP не должен быть последней осязаемой точкой, не должно быть "сейчас запилим MVP, а дальше посмотрим". Если вы так делаете, то тогда это у вас действительно "перый сырой релиз".
Бич флагманов начала 2020х - батарейка. Напихать в топовый смарт уйму всего и новейший-мощнейший проц - и запитать батарейкой на 4500. Неужто производители так продвигают зарядки, особенно беспроводные?
А какой подход к актуализации? Отмечается ли дата внесения, триггеры пересмотра и т.д.? Если по какому-то конкретному вопросу находится новый, более удачный материал, ставится ли он на замену старому или добавляется в базу?
Напрашивается вопрос: не отказаться ли тогда вообще от оценки сроков? И что говорить заказчику? "Когда будет готов продукт?" - "А хз" - получается вот так, зато честно?
А вопрос "Ну когда?" один из самых, если не самый частый.
Отличная статья, полезные комментарии. Однозначно в закладки.
Здорово, когда человек ищет способы оптимизации и организации своего рабочего процесса. И уж тем более самому становится приятно, когда эти усилия начинают приносить тебе пользу. Важный момент - не почивать на лаврах, не считать, что какая-то находка является серебряной пулей или высеченной в камне. Проще говоря, не становится заложником собственных идей.
Частично прочувствовал это на себе, когда перешёл из администрирования в менеджмент. Да, это всё ещё я и верхнеуровнево задачи остались задачами, пускай и иного содержания. Но характер работы другой, темп другой - и весь свой инструментарий в такой ситуации нужно пересматривать.
Конкретно по тексту у меня к автору один вопрос по самому первому пункту про сортировку писем. Используется ли во входящих/архиве сортировка по папкам и какие-либо другие фичи? Флаги важности, цветовая маркировка и т.п.
В целом-то тема интересная. Нужно уметь вплетать сервые и неинтересные задачи оптимизации в волшебную и захватывающую череду задач по разработке новых фичей. Но... удалось ли это?
В статье поднят важный вопрос: как совместить оптимизацию ресурсов с разработкой? Командом нужно было внести оптимизацию в планы, скорректировать бэклоги. Всё это означает ровно то, что раньше команды никак не закладывали обслуживание техдолга, по крайней мере на постоянной основе. Обратная связь по итогам активности - это круто. Но сколько команд стали стали реально закладывать работы по оптимизации в свои спринты? И появилась ли общая тенденция по компании к замедлению роста потребления ресурсов?
В том виде, как рассказывается в статье, это похоже на советскую методику субботников. Год мы бросаем окурки куда попало - а потом весь завод выходит на субботник. Приезжает партийная делегация, делается фото для Комсомольской правды - и всё возвращается на круги своя.
Так с ходу я бы посмотрел в сторону другой концепции. Сначала поработать предметно с 3-4 проектами. Внедрить там "лучшие инженерные практики". А потом анонсировать такой вот "месячник оптимизации", провести стартовый митос со спикерами от этих команд. И дальше по мотивам ретроспективы заниматься внедрением хорошо зарекомендовавших себя подходов в максимальное число команд. Будь то какой-то внутренний гайд или ещё что-то.
Энивей, продвигать оптимизацию в компании лучше, чем не продвигать. Будет интересно почитать про следующую активность!
Вы говорите про четыре проекта, а опыт индустрии - это "сто тысяч миллионов" проектов. Означает ли это, что опыт индустрии однозначно подойдёт конкретно вашему проекту? Нет. Но ваш личный опыт совершенно точно не перечёркивает опыт индустрии. Т.к. в её масштабах это отклонение - это даже не песчинка на берегу океана.
Но в целом соглашусь со мнением, высказанным выше. Взгляд на менеджмент немного отдаёт нафталином.
Это называется "изобрести велосипед". Придумать, что-то уже придуманное. И это даже будет работать.
С таким же успехом можно было бы нарисовать диаграмму Ганта, например. Или Канбан доску, перерисовывая её раз в день-другой для чистоты.
Тут всё в кучу. Думаю, это и является причиной выгорания. Когда ты "и жнец, и швец" в рамках ЛЮБОЙ роли, ты выгоришь. Точка.
Давайте попробуем разобраться и навести порядок.
Сначала поговорим про скрам. Считать скрам-мастера сугубо "модератором митингов" и говорить, что "это чаще всего кто-то из исполнителей" - это уже маленечко выстрел себе в ногу. СМ может и не участвовать на митингах, например. А ещё он помогает идентифицировать и устранять преграды, предлагает улучшения процессов, работает с обратной связью внутри команды. Важно понимать, что настоящего скрама без СМ не бывает. А значит если команда работает по всамделашнему скраму, то "функции СМ" не обязаны прилипать к тимлиду. А в компаниях, где больше 2-3 проектов, это и вовсе маловероятно.
Теперь конкретно о тимлидах в скраме. Да, такой роли там не описано. Но там и роли CEO компании нет, и бухгалтера нет, и уборщицы. Это означает лишь то, что для тимлида скрам не прописывает каких-то конкретных полномочий или ответственности.
Должен ли тимлид быть архитектором, тестировщиком, кем там угодно ещё? Это уже вопрос организации работы внутри компании. И тут давайте сделаем отсылку к структуре компании. У вас может быть всего один продукт - тогда одна команда и есть вся компания. У вас может быть аутсорс, где работают сотни человек на десятках проектов. Очевидно, что это будет влиять на наполнение роли тимлида. Я не буду углубляться в разделение обязанностей между тимлидом и эйчаром, что является довольно частым случаем, а лушче скажу, что сам подразумеваю под тимлидом.
Для меня тимлид - это прежде всего техлид. Человек, отвечающий за развитие основной технической компетенции своих подопечных (которые строго говоря не обязательно его подчинённые). Техническое совершенство продукта за авторством команды в этом случае - производная. Тимлид это не ультра-сеньор с кучкой вечных джунов за спиной. Это ревьер и ментор. Сильный тимлид растит специалистов. Он может, но не обязан участвовать непосредственно в разработке, построении архитектуры. Что бы он ни делал, его верхреуровневая цель заключается в том, чтобы научить подопечных делать это самим.
Если подытожить, то роль "Тимлид" в описании вакансии на сегодня столь же туманна, как и "Менеджер". Что за этим скрывается - загадка. Заранее задать все вопросы и чётко обозначить рамки - это снизить вероятность выгорания.
Поисковые движки же не имеют контрактов и лицензий вообще со всеми. Я могу ввести поисковый запрос, мне в выдаче будут результаты с таких ресурсов вперемешку с проплаченными позициями. Т.е. поискових демонстрирует изображение со стока и берёт бабло с заказчика рекламы. Такое же косвенное коммерческое использования, как и в случае с ИИ.
Только в случае с ИИ ещё и доказать сложнее. Если поисковик по конкретному запросу показал конкретное изображение, то как тот же Гетти докажет, что ИИ движок каким-то образом использует изображения с сайта при генерации новых?
Чиновники и делегирование им части прав (вместе с ответственностью) нужны в т.ч. и для упрощения принятия решений. В Париже проживает 2 миллиона человек. Чтобы решить, нужны ли городу 15 тысяч электросамокатов нужно опросить 2 миллиона человек? Окей, граждан Франции с избирательным правом там меньше, но всё же. А за чей счёт банкет? Это прокатчики оплатят мероприятие?
А когда выдавали лицензии, тоже опрос проводился? Не одну лицензию - три.
Я поддерживаю демократические ценности, но в этой ситуации это действительно похоже на какой-то популизм и подковёрные игры.
Зерокод - это не уникальная тенденция в IT. Всё вокруг, что входит в нашу повседневную жизнь, упрощается, унифицируется, на каком-то этапе мы уже начинаем считать это нативно понятным. Хотя в момент своего появления этого могли быть чем-то ну очень сложным и не для всех. Например, первые компьютеры и мой ноубтук, с которого я пишу этот коммент.
Я всячески приветствую зекород-решения. Они не убьют энтерпрайз разработку, кастомную разработку и вот это вот всё. А жизнь многих и многих пользователей/заказчиков станет легче.
Ну, это он целей статьи зависит и очерченной ЦА. На серьёзный форум с такой презентахой не пойдёшь. На науч-поп ресурсе для создания "дружелюбного лица компании" - вполне. А раз это корпоративный блог, то какой вариантов ближе, тут вроде как понятно.
В целом ситуация, которая могла случиться не только с архитектором и не только в Сбере. Позиция в компании есть, жёсткого перечня требований нет. Нашёлся кандидат, который устроил внутреннего заказчика вакансии. Виноват ли сам кандидат, что его приняли? Нет. В принципе можно ли оперировать термином "вина"? Только если по итогу этот найм будет признан неудачным.
Так что пока можно пожелать удачи герою статьи и пускай всё получится.
Я скорее вижу позитивный посыл в статье: инвестиции в себя оправдались. Это мотивирует.
Значительная часть комментов, "развенчивающих миф" о прорывном Айфоне, написана по лекалу "Да вот что Эппл, да я вот уже тогда...". Как мне кажется, это скорее попытки возвысить себя и получить свою минуту славы.
На рынке всегда были культовые телефоны - но никогда не было бескомпромиссных телефонов. Минусы и косяки были и будут у всех. Тогда первый Айфон выглядел устройством из другой лиги. Нынешние Айфоны не отличаются настолько от конкурентов, но тогда...
Должны ли мы быть благодарны Джобсу и его команде или же они вынесли приговор рынку мобильных телефонов? Мы ходим в унифицированной одежде, ездим на унифицированных машинах. Те люди, которые сладостно вспоминают N-Gage сейчас ходят по улицам в леопардовых меховых шортах и ездят на ванне с моторчиком? Нет. Ностальгия в комментах и реальный мир всё же разные вещи.
Со своей стороны по практикам коммуникации могу поделиться следующим наблюдением. Менеджер на проекте всегда в меньшинстве (ну, в большинстве случаев). На проекте может быть 1 разработчик или 5, или 10. А менеджер один.
Да, ты не говоришь постоянно <Обращение> + <вводная информация>... и не требуешь квитанцию каждый раз. Но ты всё равно используешь эти приёмы чаще остальных - и этим выбиваешься из общего потока коммуникации. Как менеджер, ты ратуешь за эффективную коммуникацию, учишь всех вести её правильно, по необходимости использовать все вот эти приёмы. Всё равно в твоей речи они будут встречаться чаще, чем у других членов команды.
Для меня мастерство менеджера во много определяется способностью "не набивать оскомину" своим менеджерским подходом и стилем. Когда ты одновременно растворяешься в общем потоке коммуникации и при этом решаешь менеджерские задачи.
>>Таким образом мы выводим главную проблему в коммуникации — потеря данных.
Если мы проводим линию раздела между общением и коммуникацией, то надо в таком случае проводить такую же линию между данными и информацией.
"Потеря данных при коммуникации" это когда в мессенджере не ушло сообщение. Но если при этом собеседник всё понял правильно, то потери информации не произошло. Иными словами, при помощи данных мы передаём информацию. Можно передать данные, но при этом не передать информацию. Передать информацию без передачи данных невозможно.
Это, кстати, проблема менеджмента - данные без информации. В статье правильно подмечена одна из таких ситуаций - повисшие вопросы.
В общем, я бы сформулировал главную проблему чуть иначе: неэффективная передача информации.
Очень приятная и лаконичная статья, спасибо!
В комменте про самый попсовый термин оставлю такой же попсовый коммент - надо быть гибче)
Действительно, ситуации бывают разные. На первый взгляд идти на давно устоявшийся рынок энтерпрайз приложений с MVP бессмысленно. Но обязательно ли сразу стучаться в двери приёмных топ-компаний? Нельзя ли обкатать MVP на игроках попроще? Ну, здорово, когда это возможно.
Соглашусь, что важной пользой от MVP является реальная обратная связь, возможность проведения полевых исследований. Если не на стадии MVP, то когда? Уже слышу шум водопада.
Последнее, что отмечу, это место MVP в роадмапе продукта. MVP не должен быть последней осязаемой точкой, не должно быть "сейчас запилим MVP, а дальше посмотрим". Если вы так делаете, то тогда это у вас действительно "перый сырой релиз".
Бич флагманов начала 2020х - батарейка. Напихать в топовый смарт уйму всего и новейший-мощнейший проц - и запитать батарейкой на 4500. Неужто производители так продвигают зарядки, особенно беспроводные?
А можно узнать, что с ним не так?
А что можно было бы использовать для описания кодом диаграмм бизнес-процессов? Где несколько акторов (swim lanes), блоки условий и вот это вот всё?
А какой подход к актуализации? Отмечается ли дата внесения, триггеры пересмотра и т.д.? Если по какому-то конкретному вопросу находится новый, более удачный материал, ставится ли он на замену старому или добавляется в базу?
Напрашивается вопрос: не отказаться ли тогда вообще от оценки сроков? И что говорить заказчику? "Когда будет готов продукт?" - "А хз" - получается вот так, зато честно?
А вопрос "Ну когда?" один из самых, если не самый частый.
Отличная статья, полезные комментарии. Однозначно в закладки.
Здорово, когда человек ищет способы оптимизации и организации своего рабочего процесса. И уж тем более самому становится приятно, когда эти усилия начинают приносить тебе пользу. Важный момент - не почивать на лаврах, не считать, что какая-то находка является серебряной пулей или высеченной в камне. Проще говоря, не становится заложником собственных идей.
Частично прочувствовал это на себе, когда перешёл из администрирования в менеджмент. Да, это всё ещё я и верхнеуровнево задачи остались задачами, пускай и иного содержания. Но характер работы другой, темп другой - и весь свой инструментарий в такой ситуации нужно пересматривать.
Конкретно по тексту у меня к автору один вопрос по самому первому пункту про сортировку писем. Используется ли во входящих/архиве сортировка по папкам и какие-либо другие фичи? Флаги важности, цветовая маркировка и т.п.