Комментарии: 14
🦾
. Team lead (уши и рот) – единая входная точка для бизнеса, которая отвечает за сроки поставки решений и технический бэклог и состояние команды, создает условия для работы Senior и Middle
. Senior (мозг) – отвечает за качество и работоспособность всей системы, а значит: принимает технические решения, имеет право вето, тушит пожары, создает технические условия для работы Middle
. Middle (руки) – отвественный за работоспособность, написанного им кода: согласует решения с Senior, пилит фичи и проверяет что они работают
Примечания
. Я назвал их "Team lead", "Senior" и "Middle", потому что нет более подходящих слов (кроме тех, что в скобочках), на самом деле на роли "Middle" может быть человек уровня Senior, так и Junior
. Это РОЛИ, а значит их может в себе совмещать в себе один и тот же человек
. При этом Team Lead и Senior должно быть максимум по одному, а вот Middle может быть много, но в идеале в пределах 10-ти
. Team Lead может не иметь технических навыков (таких я назыаю PM, но это не снимает с них ответственности, описанной выше)
. Я намеренно не включал QA, DevOps, CTO, Архитектор, etc. потому что это или может переиспользовать написанное выше, или более гипербализированная версия (например, CTO это Team Lead, только который еще и за ФОТ отвечает)
Почему именно такая команда
. Решения ставновятся (не)правильными только после того, как вы их применили, поэтому кто-то должен просто брать на себя ответственность за то, чтобы выбрать какой-то путь и ждать результата. Если такое решение будут пытаться утвердить несколько человек, то у них возникнут большие проблемы, соответственно, капитан (Senior) должен быть всего один.
. Коммуникация с бизнесом – боль. Ее бывает невероятно много. Причем как и на вход в команду, так и на выход. Одновременно с этим, бизнес очень часто не умеет общаться с разрабами и наоборот, поэтому пускать их друг к другу на постоянной основе точно не стоит. Их можно знакомить и оставлять на какое-то время (создание фичи), но вся коммуникация и ответственность должна быть в одних руках (Team Lead)
. Senior дополняют Middle, а Middle дополняют Senior: Middle может получить все нужные ему знания, Senior может реализовать себя как "сенсей" и при этом сам научиться, структурировав свои знания во время передачи их Middle разработчику. Такой Уроборос позволяют им обоим расти и получать от этого удовольтвие.
Два Senior разработчика могут (для начала, разосраться, но это я выше писал, поэтому в данной ситуации) задавать друг другу слишом мало вопросов (например, из-за стеснения) и пилить какую-нибудь невероятную херь просто потому что не решились ее заранее обсудить (это в целом про зрелось, но это отдельный топик)
Как такую создать
– Открыто и явно проговорить кто какую роль на себя берет и чтобы Senior явно передали права на решения по бизнес-части Team Lead, а Middle явно передали права за технические решения Senior
– Установить хорошую, открытую и постоянную коммуникацию между всеми этими звеньями
– Дать возможность Senior делать технические решения и нанимать людей в соответствии с ними
В чем опасность
– Если у Team Lead плохо прокачаны Soft skills и нет "стальных яиц" с умением говорить "нет" как разрабам, так и бизнесу, все будут выгорать, будет страдать бизнес и начнется текучка
– Если выбрать плохого Senior, то он поведет всю команду в бездну, при этом если не дать Senior право принимать опасные решения, то хороший Senior тоже ничего не способен будет сделать
– Если Senior не готовы слушать Middle-ов или Middle-ы соглашаться с итоговыми решениями Senior схема не сработает, поэтому именно Senior должен собирать команду
. Senior (мозг) – отвечает за качество и работоспособность всей системы, а значит: принимает технические решения, имеет право вето, тушит пожары, создает технические условия для работы Middle
. Middle (руки) – отвественный за работоспособность, написанного им кода: согласует решения с Senior, пилит фичи и проверяет что они работают
Примечания
. Я назвал их "Team lead", "Senior" и "Middle", потому что нет более подходящих слов (кроме тех, что в скобочках), на самом деле на роли "Middle" может быть человек уровня Senior, так и Junior
. Это РОЛИ, а значит их может в себе совмещать в себе один и тот же человек
. При этом Team Lead и Senior должно быть максимум по одному, а вот Middle может быть много, но в идеале в пределах 10-ти
. Team Lead может не иметь технических навыков (таких я назыаю PM, но это не снимает с них ответственности, описанной выше)
. Я намеренно не включал QA, DevOps, CTO, Архитектор, etc. потому что это или может переиспользовать написанное выше, или более гипербализированная версия (например, CTO это Team Lead, только который еще и за ФОТ отвечает)
Почему именно такая команда
. Решения ставновятся (не)правильными только после того, как вы их применили, поэтому кто-то должен просто брать на себя ответственность за то, чтобы выбрать какой-то путь и ждать результата. Если такое решение будут пытаться утвердить несколько человек, то у них возникнут большие проблемы, соответственно, капитан (Senior) должен быть всего один.
. Коммуникация с бизнесом – боль. Ее бывает невероятно много. Причем как и на вход в команду, так и на выход. Одновременно с этим, бизнес очень часто не умеет общаться с разрабами и наоборот, поэтому пускать их друг к другу на постоянной основе точно не стоит. Их можно знакомить и оставлять на какое-то время (создание фичи), но вся коммуникация и ответственность должна быть в одних руках (Team Lead)
. Senior дополняют Middle, а Middle дополняют Senior: Middle может получить все нужные ему знания, Senior может реализовать себя как "сенсей" и при этом сам научиться, структурировав свои знания во время передачи их Middle разработчику. Такой Уроборос позволяют им обоим расти и получать от этого удовольтвие.
Два Senior разработчика могут (для начала, разосраться, но это я выше писал, поэтому в данной ситуации) задавать друг другу слишом мало вопросов (например, из-за стеснения) и пилить какую-нибудь невероятную херь просто потому что не решились ее заранее обсудить (это в целом про зрелось, но это отдельный топик)
Как такую создать
– Открыто и явно проговорить кто какую роль на себя берет и чтобы Senior явно передали права на решения по бизнес-части Team Lead, а Middle явно передали права за технические решения Senior
– Установить хорошую, открытую и постоянную коммуникацию между всеми этими звеньями
– Дать возможность Senior делать технические решения и нанимать людей в соответствии с ними
В чем опасность
– Если у Team Lead плохо прокачаны Soft skills и нет "стальных яиц" с умением говорить "нет" как разрабам, так и бизнесу, все будут выгорать, будет страдать бизнес и начнется текучка
– Если выбрать плохого Senior, то он поведет всю команду в бездну, при этом если не дать Senior право принимать опасные решения, то хороший Senior тоже ничего не способен будет сделать
– Если Senior не готовы слушать Middle-ов или Middle-ы соглашаться с итоговыми решениями Senior схема не сработает, поэтому именно Senior должен собирать команду
🦾
🦾
🦾
I
Решение конфликта между сеньорами бывают разные:
- оценка доступных ресурсов, планируемых трудозатрат и бизнесовое обоснование по каждому решению
- 2 столбика плюсы и минусы по каждому решению. 2 по 10 минут раунда, в первом один критикует, второй ищет плюсы в своём решение, потом меняются ролями, в конце считают плюсы и минусы
- как ты обозначил разделение ролей, но это задача СТО, грейд сеньоров по PDP в разных нишах, у каждого есть право принятия окончательного решения только в своей
- оценка доступных ресурсов, планируемых трудозатрат и бизнесовое обоснование по каждому решению
- 2 столбика плюсы и минусы по каждому решению. 2 по 10 минут раунда, в первом один критикует, второй ищет плюсы в своём решение, потом меняются ролями, в конце считают плюсы и минусы
- как ты обозначил разделение ролей, но это задача СТО, грейд сеньоров по PDP в разных нишах, у каждого есть право принятия окончательного решения только в своей
I
Я тут, кстати, экспериментирую с тем, чтобы тимлид в командах был вовсе не синьором в технологии, а наоборот, его склад ума был больше за процессы и людей. Чтобы если есть техническая проблема, то он не тянул экспертизу на себя, а держал градус безумия и каргокульта в пределах палаты отдела в норме
🦾
Ivan Zhuravlev
Решение конфликта между сеньорами бывают разные:
- оценка доступных ресурсов, планируемых трудозатрат и бизнесовое обоснование по каждому решению
- 2 столбика плюсы и минусы по каждому решению. 2 по 10 минут раунда, в первом один критикует, второй ищет плюсы в своём решение, потом меняются ролями, в конце считают плюсы и минусы
- как ты обозначил разделение ролей, но это задача СТО, грейд сеньоров по PDP в разных нишах, у каждого есть право принятия окончательного решения только в своей
- оценка доступных ресурсов, планируемых трудозатрат и бизнесовое обоснование по каждому решению
- 2 столбика плюсы и минусы по каждому решению. 2 по 10 минут раунда, в первом один критикует, второй ищет плюсы в своём решение, потом меняются ролями, в конце считают плюсы и минусы
- как ты обозначил разделение ролей, но это задача СТО, грейд сеньоров по PDP в разных нишах, у каждого есть право принятия окончательного решения только в своей
Ты говоришь про 2-х сеньоров в рамках одной команды?
Первый пункт не понял, второй мы практикуем между сеньорами из разных команд (но это, скорее как консультация), а с третьим согласен
В целом, я считаю, что нужно (1) или чтобы один передал больший приоритет в решениях другому, (2) или ответственность делилась так, чтобы не пересекаться (хоть по модулям в рамках одной системы)
Первый пункт не понял, второй мы практикуем между сеньорами из разных команд (но это, скорее как консультация), а с третьим согласен
В целом, я считаю, что нужно (1) или чтобы один передал больший приоритет в решениях другому, (2) или ответственность делилась так, чтобы не пересекаться (хоть по модулям в рамках одной системы)
I
🦾 IT-Качалка Давида Шекунца 💪
Ты говоришь про 2-х сеньоров в рамках одной команды?
Первый пункт не понял, второй мы практикуем между сеньорами из разных команд (но это, скорее как консультация), а с третьим согласен
В целом, я считаю, что нужно (1) или чтобы один передал больший приоритет в решениях другому, (2) или ответственность делилась так, чтобы не пересекаться (хоть по модулям в рамках одной системы)
Первый пункт не понял, второй мы практикуем между сеньорами из разных команд (но это, скорее как консультация), а с третьим согласен
В целом, я считаю, что нужно (1) или чтобы один передал больший приоритет в решениях другому, (2) или ответственность делилась так, чтобы не пересекаться (хоть по модулям в рамках одной системы)
про первый пункт я просто описал базовые факторы принятия решения, которые не связаны напрямую с техническим обоснованием, а больше были про риски и менеджмент, так проще на первом этапе отсеять большинство решений
🦾
Ivan Zhuravlev
Я тут, кстати, экспериментирую с тем, чтобы тимлид в командах был вовсе не синьором в технологии, а наоборот, его склад ума был больше за процессы и людей. Чтобы если есть техническая проблема, то он не тянул экспертизу на себя, а держал градус безумия и каргокульта в пределах палаты отдела в норме
Абсолютно согласен
По моему опыту из-за ресурсов происходит так, что Senior становится еще и Team Lead
И всегда, когда Team Lead был отдельным человеком, который больше про людей и бизнес, но в целом шарит в разработке (в идеале Junior+ или Middle-), то процессы шли намного намного лучше
По моему опыту из-за ресурсов происходит так, что Senior становится еще и Team Lead
И всегда, когда Team Lead был отдельным человеком, который больше про людей и бизнес, но в целом шарит в разработке (в идеале Junior+ или Middle-), то процессы шли намного намного лучше
I
🦾 IT-Качалка Давида Шекунца 💪
Абсолютно согласен
По моему опыту из-за ресурсов происходит так, что Senior становится еще и Team Lead
И всегда, когда Team Lead был отдельным человеком, который больше про людей и бизнес, но в целом шарит в разработке (в идеале Junior+ или Middle-), то процессы шли намного намного лучше
По моему опыту из-за ресурсов происходит так, что Senior становится еще и Team Lead
И всегда, когда Team Lead был отдельным человеком, который больше про людей и бизнес, но в целом шарит в разработке (в идеале Junior+ или Middle-), то процессы шли намного намного лучше
вот я тоже к этому прихожу, что так намного эффективнее, плюс он внутри команды лучше понимает атмосферу, нежели технарь
V
идея: игровое шоу под названием «Синдром самозванца». Вы
берете 10 сеньоров и говорите им, что среди них есть один
продажник, которого научили произносить модные
DevOps-словечки. Чтобы победить, им нужно выяснить, кто
фальшивый разработчик. Нюанс: нет никакого продажника
берете 10 сеньоров и говорите им, что среди них есть один
продажник, которого научили произносить модные
DevOps-словечки. Чтобы победить, им нужно выяснить, кто
фальшивый разработчик. Нюанс: нет никакого продажника
🦾
Vladislav Yucca Y.
идея: игровое шоу под названием «Синдром самозванца». Вы
берете 10 сеньоров и говорите им, что среди них есть один
продажник, которого научили произносить модные
DevOps-словечки. Чтобы победить, им нужно выяснить, кто
фальшивый разработчик. Нюанс: нет никакого продажника
берете 10 сеньоров и говорите им, что среди них есть один
продажник, которого научили произносить модные
DevOps-словечки. Чтобы победить, им нужно выяснить, кто
фальшивый разработчик. Нюанс: нет никакого продажника
Или 10 джуниоров, а один из них сеньор
Нюанс: все сеньоры
Нюанс: все сеньоры