Вижу в начале статьи, что много требований к системному аналитику пересекаются с требованиями к архитектору. То есть знание того как устроена система, какие есть связи, как сделать оптимальное решение ввиду всего этого. И также состав ваших команд не предполагает наличие архитектора либо вы его оставили за скобками.
Как вы считаете чем бы вам тогда помог архитектор и кто сейчас выполняет его роль?
Если можно заменить письмом или статусом в чате - почему не просите ПМа сделать именно так? Просто вижу несколько причин
Нет доверия у ПМа к команде
ПМ хочет контролировать все и вся
Процессы не настолько автоматизированы/настроены и приходится руками собирать статусы
Или же статус не интересен вам, но интересен и важен остальным присутствующим, кто может задать вопросы в онлайне и почувствовать ответственность за результаты. командный дух и все такое. Но это больше про спринт ревью/демо и тд (которые тоже спокойно можно увести в оффлайн режим и заменить отпиской в чате, но в скраме как-то до этого недодумались)
К сожалению, не все события именовались корректно в этом случае и синк может означать совместно принятие архитектурного решения, проработка стратегии тестирования по проекту и так далее. Бывают онлайн синки, которые носят характер дать статус, но это скорее связано, что не всегда легко понять по джире в чем проблема, почему что-то не двигается и почему одна команда не предупредила другую завершив свою часть работ. Это решает автоматизацией процесса (к этому надо придти на уровне всей компании)
Статусы задач вы можете сами посмотреть в Jira
Тут ответил частично выше. В идеале - да. Стараюсь по максимум делать под сложные проекты отдельный роадмап (джира план) + джира дашборд. Тут видим и все статусы команд, и процент завершения и потенциальные блокеры. Но это не покрывает 100% кейсов.
Асинхронные коммуникации намного дешевле и удобнее.
100% согласен, это используем по максимуму. Но сразу скажу бывают кейсы когда несколько сотрудников общаются уже пару часов в чате и каждый вообще не понимает друг друга, или когда сложно объяснить словами, а проще пошарить экран и показать на практике.
Внедрите в компанию "культуру митингов"
Вот эта часть наверно самая сложная. Можно долго про это рассказывать, но пока нет инструмента для автоматической валидации, это все же будет не правилом, а рекомендацией. Про вариант, когда против каждого пункта указан исполнитель, я по сути упомянул в секции про Постмиты (то что вы мусором назвали), под каждый спойлером там именно такой список с действиями, сроками и исполнителями.
Научитесь уже делегировать задачи
Мы не в идеальном мире живем, не все задачи можно делегировать и не все подчиненные хотят этими задачами заниматься. Что к этому нужно стремиться - согласен.
5 и 6 правило примерно соответствуют решению - нормально делай, нормально будет. Вроде и не поспоришь, но покажите мне где это работает на 100 процентов?
Хорошо писать книжки и статьи на тему эффективного управления, там много можно замести под коврик и не показывать исподнего. Строить процессы лучше всего на примере сферического коня в вакууме, когда нет людей. Как только появляются люди (причем с самыми разными навыками и характерами) все резко становится не таким красивым и не таким простым.
Это тот самый уровень абстракции что отделяет бизнес от разработчиков
Ключевая роль руководителя (например, продукта) быть как раз этим связующим звеном и иметь контекст обеих сторон и давать возможность по минимуму участвовать в различных синках с другими командами (например, с другим отделов разработки, аналитиками, локализаторами и тд)
Другое дело что всё это заменяется бордой в джире
Уверены, что заменяется? Дополняется и облегчает работу - да. Вы пытались когда-нибудь сами организовать работу по проекту в который входит 10+ команд из разных отделов, с 10 разными проектами в джире, разными процессами поставки задач и SLA на их выполнение?
Если да, буду рад выслушать ваш вариант как все сделать правильно и не про...ть сроки и не получить на выходе что-то вообще не похожее на изначальное ТЗ.
Есть правда продукты типа nginx или Μοzilla
Есть стартапы из 10 человек, кто пилит здоровенный продукт сидя в одном подвале, и есть банковское подразделение из 1000+ сотрудников сидящих по всему миру. И цель у обоих продуктов одна - заработать денег. Основатель Nginx кстати заработал, продав это все дело... а теперь опять вышел со своих Free Nginx. Что-то пошло не так?
Выводы как будто chatGPt писал, несогласованность и абстрактность некоторых фраз очень сбивает с толку.
Также бы добавил в статью кейсы с тем как использовать канарейку в случае когда у вас в релизе N сервисов. Подход в статье усложнится раза в три, так как придется настраивать балансировку между версиями на уровне http или что ещё сложнее на уровне Kafka и аналогичных тулов по работе с событиями.
Так что слепо вкрячить деплой через Хелм не поможет в системах чуть сложнее чем пара crud сервисов.
Плюсую за Any.do. Просто, понятно и можно виджет растянуть на весь экран телефона, чтобы просто доп экран был вместо заметок. Еще удобно, что календарь с гугловым дружит в бесплатной версии.
Из рабочих инструментов согласен, выбор не сильно большой ввиду требований безопасности и количеству интеграций. А для личного пользования можно с ума сойти выбирая идеальный инструмент. Для себя пока остановился на Any.do. чисто как ежедневник со списками задач плюс записная книжка.
Последний раз когда анализировал решения подобного рода(канбан доски) часто сталкивался, что не хватает фришного аккаунта. То есть часть функционала идет в корпоративной версии для командной работы, ну и в целом упор больше на командную разработку, чем на индивидуальное использование. В timestripe смотрю очень кто-то вдохновлялся Notion, тут несколько нестандартная визуализация Канбан борды))
Не сочтите аналогией "пойти погуглить", но я бы посоветовал обратиться к chatGPT. В последнее время некоторые мануалы очень просто заменяются парой обращений к ИИ. Главное задать контекст и возможно вкинуть в нее существующий скрипт пайплайна и сказать в какое место воткнуть интеграцию по отправке аннотации (если нет запрета от СБ на работе). А дальше для верности можно попросить проверить ее саму это же решение на ошибки.
Спасибо, в целом понято. У меня в принципе похожая ситуация (платформенные команды, которые еще и между собой зависят от проекта к проекту). Если говорить о таком квартальном планировании, получается к нему уже все проекты должны быть предварительно проработаны технически, чтобы понимать где какая связь возникает? За сколько времени вы начинаете эту проработку и выделяете ли явно в квартале, например, последний спринт, чисто под проработку и ресерч проектов следующего квартала? У меня боль такая, что при планировании не хватает времени на детальную проработку, а так как проекты сложные технически то там может быть 5+ команд спокойно. И вот эти команды потом становятся блокерами. А варианты типа "сделай сам" хорошо работают когда языки одинаковые в командах, что не мой вариант))
Если кто-то отказал, уже за рамками выравнивания команда продукта привлекает руководителя и занимается переприоритизацией
Интересует вот такой момент. На выравнивании вам отказали в 2 проектах. Другой команде в одном проекте ну и так далее. В итоге у вас освободилось капасити и у кого-то тоже. Митинг выравнивания закончился. Счастливые команды у кого все ок побежали делать работу а оставшиеся будут пытаться придумать как им быть и какие проекты они могут сделать без чужой помощи? Или какой флоу в таком случае?
Да, в целом, почти любая тема имеет какой-то теоретический базис под капотом. Но лично мне всегда интересно изучать что-либо на практических примерах. И желательно узнавать это от людей, работающих в моей сфере(так как есть все-таки специфика), а не в государственных организациях, банках. Много книг написаны в 60-е - 80-е на примерах Американских компаний и их уже тяжеловато воспринимать.
Все естественно зависит от конкретного случая, но, в первую очередь, бизнес хочет делать функционал для клиента, и лучше, если быстро. Поэтому разработчики в таких случаях становятся T-shape, чтобы не расширять штат еще больше. То есть делают работу и разработчика и девОпса, и куа. И в этом случае, какими-то вещами будут пренебрегать.
Есть конечно и примеры полностью кроссфункциональных команд в стартапах, где сразу нанимают исходя из потребности X dev + Y qa + devOps +дизайнер + ПО. Но это обычно дороже, особенно в небольших масштабах.
Понял, не про тот рост подумал. В случае штата решает бизнес, если продукт узкоспециализированный и не требует инновации каждый день добавлять - возможно ок. Но что если это типа Амазона? Они тоже только книжками торговали.. а сейчас уже только сокращают десятками тысяч.
Типа сидеть за N сумму на легаси проекте и плевать в потолок? Я пока еще не слишком стар для этого д..а)) Шутка если что. Никого не осуждаю - не для всех работа - хобби и не каждая работа должна быть хобби.
Я для себя открыл цикл идеального развития скилов. Сначала вписываешься во что-то неимоверно интересное и сложное, доводишь до ума, набираешься экспертизы, а потом немного выдыхаешь. И так по кругу. Без выдоха - выгораешь, без сложностей деградируешь.
Вижу в начале статьи, что много требований к системному аналитику пересекаются с требованиями к архитектору. То есть знание того как устроена система, какие есть связи, как сделать оптимальное решение ввиду всего этого. И также состав ваших команд не предполагает наличие архитектора либо вы его оставили за скобками.
Как вы считаете чем бы вам тогда помог архитектор и кто сейчас выполняет его роль?
Если можно заменить письмом или статусом в чате - почему не просите ПМа сделать именно так? Просто вижу несколько причин
Нет доверия у ПМа к команде
ПМ хочет контролировать все и вся
Процессы не настолько автоматизированы/настроены и приходится руками собирать статусы
Или же статус не интересен вам, но интересен и важен остальным присутствующим, кто может задать вопросы в онлайне и почувствовать ответственность за результаты. командный дух и все такое. Но это больше про спринт ревью/демо и тд (которые тоже спокойно можно увести в оффлайн режим и заменить отпиской в чате, но в скраме как-то до этого недодумались)
Попробую прокомментировать по пунктам.
К сожалению, не все события именовались корректно в этом случае и синк может означать совместно принятие архитектурного решения, проработка стратегии тестирования по проекту и так далее. Бывают онлайн синки, которые носят характер дать статус, но это скорее связано, что не всегда легко понять по джире в чем проблема, почему что-то не двигается и почему одна команда не предупредила другую завершив свою часть работ. Это решает автоматизацией процесса (к этому надо придти на уровне всей компании)
Тут ответил частично выше. В идеале - да. Стараюсь по максимум делать под сложные проекты отдельный роадмап (джира план) + джира дашборд. Тут видим и все статусы команд, и процент завершения и потенциальные блокеры. Но это не покрывает 100% кейсов.
100% согласен, это используем по максимуму. Но сразу скажу бывают кейсы когда несколько сотрудников общаются уже пару часов в чате и каждый вообще не понимает друг друга, или когда сложно объяснить словами, а проще пошарить экран и показать на практике.
Вот эта часть наверно самая сложная. Можно долго про это рассказывать, но пока нет инструмента для автоматической валидации, это все же будет не правилом, а рекомендацией. Про вариант, когда против каждого пункта указан исполнитель, я по сути упомянул в секции про Постмиты (то что вы мусором назвали), под каждый спойлером там именно такой список с действиями, сроками и исполнителями.
Мы не в идеальном мире живем, не все задачи можно делегировать и не все подчиненные хотят этими задачами заниматься. Что к этому нужно стремиться - согласен.
5 и 6 правило примерно соответствуют решению - нормально делай, нормально будет. Вроде и не поспоришь, но покажите мне где это работает на 100 процентов?
Хорошо писать книжки и статьи на тему эффективного управления, там много можно замести под коврик и не показывать исподнего. Строить процессы лучше всего на примере сферического коня в вакууме, когда нет людей. Как только появляются люди (причем с самыми разными навыками и характерами) все резко становится не таким красивым и не таким простым.
Ключевая роль руководителя (например, продукта) быть как раз этим связующим звеном и иметь контекст обеих сторон и давать возможность по минимуму участвовать в различных синках с другими командами (например, с другим отделов разработки, аналитиками, локализаторами и тд)
Уверены, что заменяется? Дополняется и облегчает работу - да. Вы пытались когда-нибудь сами организовать работу по проекту в который входит 10+ команд из разных отделов, с 10 разными проектами в джире, разными процессами поставки задач и SLA на их выполнение?
Если да, буду рад выслушать ваш вариант как все сделать правильно и не про...ть сроки и не получить на выходе что-то вообще не похожее на изначальное ТЗ.
Есть стартапы из 10 человек, кто пилит здоровенный продукт сидя в одном подвале, и есть банковское подразделение из 1000+ сотрудников сидящих по всему миру. И цель у обоих продуктов одна - заработать денег. Основатель Nginx кстати заработал, продав это все дело... а теперь опять вышел со своих Free Nginx. Что-то пошло не так?
Выводы как будто chatGPt писал, несогласованность и абстрактность некоторых фраз очень сбивает с толку.
Также бы добавил в статью кейсы с тем как использовать канарейку в случае когда у вас в релизе N сервисов. Подход в статье усложнится раза в три, так как придется настраивать балансировку между версиями на уровне http или что ещё сложнее на уровне Kafka и аналогичных тулов по работе с событиями.
Так что слепо вкрячить деплой через Хелм не поможет в системах чуть сложнее чем пара crud сервисов.
Плюсую за Any.do. Просто, понятно и можно виджет растянуть на весь экран телефона, чтобы просто доп экран был вместо заметок. Еще удобно, что календарь с гугловым дружит в бесплатной версии.
Из рабочих инструментов согласен, выбор не сильно большой ввиду требований безопасности и количеству интеграций. А для личного пользования можно с ума сойти выбирая идеальный инструмент. Для себя пока остановился на Any.do. чисто как ежедневник со списками задач плюс записная книжка.
Последний раз когда анализировал решения подобного рода(канбан доски) часто сталкивался, что не хватает фришного аккаунта. То есть часть функционала идет в корпоративной версии для командной работы, ну и в целом упор больше на командную разработку, чем на индивидуальное использование. В timestripe смотрю очень кто-то вдохновлялся Notion, тут несколько нестандартная визуализация Канбан борды))
Не сочтите аналогией "пойти погуглить", но я бы посоветовал обратиться к chatGPT. В последнее время некоторые мануалы очень просто заменяются парой обращений к ИИ. Главное задать контекст и возможно вкинуть в нее существующий скрипт пайплайна и сказать в какое место воткнуть интеграцию по отправке аннотации (если нет запрета от СБ на работе). А дальше для верности можно попросить проверить ее саму это же решение на ошибки.
Соглашусь с коментом что Grafana не про это)) Но как говорит "если нельзя, но очень хочется, то можно".
Если у сервака торчит паблик АПИ, то проще вставить HTML со ссылкой. Вот тут пример: https://play.grafana.org/d/k5rL1wH7k/1-new-features-in-v8-2?orgId=1
В целом все логично, спасибо)
Спасибо, в целом понято. У меня в принципе похожая ситуация (платформенные команды, которые еще и между собой зависят от проекта к проекту). Если говорить о таком квартальном планировании, получается к нему уже все проекты должны быть предварительно проработаны технически, чтобы понимать где какая связь возникает? За сколько времени вы начинаете эту проработку и выделяете ли явно в квартале, например, последний спринт, чисто под проработку и ресерч проектов следующего квартала? У меня боль такая, что при планировании не хватает времени на детальную проработку, а так как проекты сложные технически то там может быть 5+ команд спокойно. И вот эти команды потом становятся блокерами. А варианты типа "сделай сам" хорошо работают когда языки одинаковые в командах, что не мой вариант))
Интересует вот такой момент. На выравнивании вам отказали в 2 проектах. Другой команде в одном проекте ну и так далее. В итоге у вас освободилось капасити и у кого-то тоже. Митинг выравнивания закончился. Счастливые команды у кого все ок побежали делать работу а оставшиеся будут пытаться придумать как им быть и какие проекты они могут сделать без чужой помощи? Или какой флоу в таком случае?
Не знал если честно, кажется стоит ознакомиться) Вот, узнал что-то новое сразу из комментов на Хабре, уже не зря статью писал.
А про спиралевидную структуру как я и думал написали в 60-е
Да, в целом, почти любая тема имеет какой-то теоретический базис под капотом. Но лично мне всегда интересно изучать что-либо на практических примерах. И желательно узнавать это от людей, работающих в моей сфере(так как есть все-таки специфика), а не в государственных организациях, банках. Много книг написаны в 60-е - 80-е на примерах Американских компаний и их уже тяжеловато воспринимать.
Зато память теперь навека, и на внуков чашек хватит)) ну и иногда поностальгировать можно
Все естественно зависит от конкретного случая, но, в первую очередь, бизнес хочет делать функционал для клиента, и лучше, если быстро. Поэтому разработчики в таких случаях становятся T-shape, чтобы не расширять штат еще больше. То есть делают работу и разработчика и девОпса, и куа. И в этом случае, какими-то вещами будут пренебрегать.
Есть конечно и примеры полностью кроссфункциональных команд в стартапах, где сразу нанимают исходя из потребности X dev + Y qa + devOps +дизайнер + ПО. Но это обычно дороже, особенно в небольших масштабах.
Понял, не про тот рост подумал. В случае штата решает бизнес, если продукт узкоспециализированный и не требует инновации каждый день добавлять - возможно ок. Но что если это типа Амазона? Они тоже только книжками торговали.. а сейчас уже только сокращают десятками тысяч.
Типа сидеть за N сумму на легаси проекте и плевать в потолок? Я пока еще не слишком стар для этого д..а))
Шутка если что. Никого не осуждаю - не для всех работа - хобби и не каждая работа должна быть хобби.
Я для себя открыл цикл идеального развития скилов. Сначала вписываешься во что-то неимоверно интересное и сложное, доводишь до ума, набираешься экспертизы, а потом немного выдыхаешь. И так по кругу. Без выдоха - выгораешь, без сложностей деградируешь.