Оставим за скобками команды, сформированные по функциональному признаку: отдел серверной разработки, отдел мобильной разработки и т.д. В функциональных командах хорошо расти новичку, но в них редко бывают возможности сделать задачу из других областей. Главная проблема функциональных команд состоит в том, что бизнес вынужден подбирать задачи, исходя из загрузки этих подразделений, а не исходя из собственных приоритетов. Например, если освободилась команда мобильной разработки, брать в работу надо задачу, где есть много мобильной разработки, даже если она десятая в приоритетах компании.
Поэтому, все чаще компании формируют кросс-функциональные команды, способные целиком взяться за любую задачу бизнеса. Это очень хорошо для бизнеса, поскольку как только одна из команд освободилась, ее можно загрузить самой приоритетной задачей. Lyft формирует свои команды именно таким образом. Типичный состав команды:
- Продакт менеджер (отвечает на вопрос что делаем и почему)
- Инженерный менеджер (отвечает на вопрос как делаем и когда будет готово, растит инженеров в команде, похоже на тимлида в других компаниях)
- Несколько серверных инженеров
- Несколько веб-инженеров
- Несколько мобильных инженеров
- Несколько инженеров по тестированию
Красота такой команды в ускоренных коммуникациях и отсутствии зависимостей от других команд. Не нужно неделями ждать, пока кто-то что-то сделает. Все делаем сами. Именно в таких командах Т-образные специалисты работают лучше всего. Попалась задача, где много серверной разработки и меньше веба? Никаких проблем! Веб разработчики помогут серверным разработчикам с простыми частями бэкэнда. И наоборот. В итоге задача будет сделана раньше.
Еще пример из Канбана. Помните, что если какой-то шаг процесса стал бутылочным горлышком, то остальные члены команды помогают разгрести завал? Я раньше мог себе представить, как разработчики помогают с тестированием. А наоборот? Вряд ли… А теперь я знаю десятки примеров, когда тестировщики помогали бэкенду написать несложные задачи, мобильные инженеры помогали веб-разработке и так далее.
Не для каждой задачи требуется эксперт. Отдаем неэкспертные задачи в руки Т-образных специалистов и таким образом высвобождаем время экспертов для устранения узких мест и проблем, где один эксперт в своем вопросе сможет разобраться с проблемой быстрее остальных.