10 ситуаций выбора тимлида

На конференции Teamlead Conf 2022 мы выкатили лёгкий тест для тех, кто хотел сделать 10 выборов тимлида в нашем банке. Он вызвал обсуждение, насколько обоснованы те или иные действия тимлида в определённых ситуациях, поэтому я постараюсь подробно объяснить, почему лучше делать так или иначе в каждой описанной ситуации.

За два дня конференции тест прошли 256 человек. В финал вышли 19 человек — это примерно 7%.

Первая ситуация, думаю, знакома многим: есть несколько задач, реализация которых зависит от результатов работы других команд разработки (вам вместе нужно их делать). Как лучше спланировать недельный спринт? Там было два варианта: поставить все кросс-командные задачи как можно плотнее и раньше, а также сделать микс из кросс-командных и внутрикомандных задач.

Ситуация встречается очень часто в архитектуре нескольких команд разработки с пересекающейся зоной ответственности: чаще всего это какая-то инфраструктурная команда и продуктовая либо две продуктовые и инфраструктурная, которые вместе делают интеграцию по API. Так вот, весь смысл гибких методологий разработки заключается в том, что плана, по сути, нет. Есть процесс разведки и исследования проблемы и проекта. То есть нельзя твёрдо полагаться на то, что другая команда сделает что-то в срок, а вы придёте и сделаете на этой основе свою часть работы. Это не строительство, когда одна бригада пришла класть кирпич поверх уже готового фундамента.

Именно поэтому нельзя занимать весь спринт кросс-командными задачами: статистически в них многое пойдёт не так, и в итоге возникнут ожидания и простои. Лучше иметь внутрикомандные (а в идеале так вообще внутрикомандные и индивидуальные) задачи, которые можно делать, пока другая команда что-то пилит.

Но и это не всё. Гораздо более широкая ситуация — выбор senior-тимлида — даже не в этом, а в причинах задержек. Конкретно — что именно привело к тому, что нужно полностью полагаться на другую команду, и можно ли этим как-то управлять.
Читать дальше →