Стартап — пора разделиться на две команды?

Я работаю в стартапе, где я начинал как единственный разработчик 3 года назад, а сейчас руковожу командой разработчиков. Всего 15 сотрудников, 8 из которых инженеры:

  • 5 iOS-разработчиков
  • 3 бэкэнд-разработчика

В настоящее время мы просто создаем приложение для iOS.

Мы начинаем немного взрослеть, и теперь у нас есть UX-дизайнер, руководитель продукта, руководитель отдела маркетинга и так далее. После длительного периода разработки продукта и нескольких очень длинных циклов выпуска мы хотим начать итерации быстрее.

Мои цели:

  1. чтобы команда работала над 2 или 3 вертикальными срезами функций параллельно.

  2. чтобы иметь возможность выпускать эти функции каждый спринт

  3. повысить ответственность и подотчетность в команде

Проблемы, которые я вижу:

  1. Ощущение «сверху вниз» — большая часть командного общения идет через меня. т.е. если у бэкэнд-разработчика есть проблема с каким-либо компонентом iOS, он может спросить меня, и тогда я поговорю с разработчиком iOS, а затем передам информацию обратно.

  2. Стендапы кажутся несфокусированными — поскольку у нас есть 8 разработчиков, работающих над разными «частями», стендапы не кажутся очень полезными, потому что на самом деле в команде нет единых усилий.

  3. Перебрасывание через забор. После планирования спринта все склонны замыкаться в себе. Мы обсудили, что нужно доделать, но разработчики склонны уходить в свои миры и, например, не брать на себя инициативу обсуждать интерфейсы между фронтом и бэкендом, бросая вещи через всю стену на QA (что обычно приходит ко мне с нашим продуктом). владелец) и др.

Вопрос: Мне интересно, есть ли смысл на данный момент разделить команду на две кросс-функциональные группы? Я надеюсь, что это приведет к следующему:

  1. У каждой «команды» будет цель спринта, которая может состоять из 1 или 2 вертикальных срезов функций для достижения. Я думаю, что может быть легче самоорганизоваться в контексте небольшой группы и выяснить, что должно произойти для достижения целей. Кроме того, я думаю, что это могло бы помочь в подотчетности, поскольку у команды будут очень конкретные цели.
  2. Стендапы могут происходить внутри каждой команды, и, следовательно, они будут сосредоточены на разблокировке и продвижении вперед, поскольку это связано с их конкретными целями спринта.
  3. Поскольку у каждой команды есть определенные цели и ответственность, они будут нести большую ответственность за такие вещи, как контроль качества, точность макетов, функциональные крайние случаи и т. д., прежде чем передать владельцу продукта для окончательного приемочного тестирования.

Я полагаю, что все вышеперечисленное может быть выполнено в контексте одной большой команды, но я пока не смог найти хороший способ сделать это.

Похоже, у вас проблема с внедрением Agile, а не с размером команды. Разделение вашей команды перед устранением основных проблем, скорее всего, удвоит ваши проблемы с интеграцией, а не уменьшит их.
Являются ли неразработчики (UX-дизайнер, руководитель отдела продукта, руководитель отдела маркетинга и т. д.) частью команды или они работают отдельно? Есть ли у команды определение готовности , включающее тестирование и интеграцию? Как бы отреагировала команда, если бы вы сказали: «Это будет опубликовано через час», как только они сообщат, что история завершена?

Ответы (2)

Есть несколько вещей, которые выделяются из вашего вопроса:

чтобы команда работала над 2 или 3 вертикальными срезами функций параллельно

Почему вы рассматриваете параллельную работу как цель? Обычно выполнение параллельной работы обходится вам с точки зрения эффективности из-за накладных расходов на переключение контекста.

если у бэкэнд-разработчика есть проблема с каким-либо компонентом iOS, он может спросить меня, и тогда я поговорю с разработчиком iOS, а затем передам информацию обратно.

Это проблема общения. Команда обсуждала это?

Стендапы чувствуют себя расфокусированными

Команда обсуждала это? Пробовали ли они что-нибудь, чтобы сделать стендапы лучше?

После Планирования Спринта все склонны замыкаться в своих силосах.

Здесь должно помочь исправление проблем со стендапом.

Я бы сказал, что самое большое улучшение, которое вы можете сделать прямо сейчас, — это начать обсуждать вещи в команде.

Возможно, разделение на две команды имеет смысл, но это решение лучше всего принимается самой командой, а не отдельным человеком.

В настоящее время мы обсуждаем вещи в команде во время совещаний по планированию и так далее. Но после этого люди склонны уходить в свои собственные миры.
Подобно комментарию, который я разместил к ответу выше, как команда из 8 человек будет работать над одной функцией? Мой опыт до сих пор таков, что это немного тесные помещения. Поэтому я подумал, что если бы мы работали над 2 или 3 слайсами одновременно, их было бы меньше, и, по сути, за каждый отвечали бы 2 или 3 разработчика.
Я прекрасно понимаю, что иногда бывает полезно работать более чем над одним делом одновременно. Но я бы не стал делать это целью, это просто то, что должно естественным образом выпасть из планирования. Команда обсудит предложенную работу, а затем решит, как лучше всего ее разделить. Смысл в том, чтобы заставить команду принимать эти решения, чтобы они были менее склонны работать изолированно.
Да, я понимаю. Команда принимает решения относительно того, что брать, каковы крайние случаи, вопросы потенциального масштаба, но потом я обнаружил, что каждый человек более или менее берет свои билеты и выполняет свою работу. Таким образом, после планирования кажется, что по-прежнему не удается продолжить командную работу.
Тогда это разговор, который вы должны иметь с командой. Почему они хотят так работать? Вы также могли бы внести некоторые предложения, возможно, они могли бы попробовать парное программирование, например? Суть в том, что команда должна хотеть делать что-то по-другому. Заставьте их говорить об этом, узнайте, какова их мотивация.

судя по тому, что вы описываете, я не думаю, что у вас есть проблемы с размером вашей команды. 5+3 вроде нормально. Может быть, мне следует добавить несколько комментариев к вашим пунктам, чтобы вы поняли, почему я думаю, что ваша проблема заключается в чем-то другом:

Цель 1 и 2. Как вы думаете, почему вам нужно обрабатывать 2–3 вертикальных среза одновременно? Если ваши циклы выпуска в настоящее время слишком длинные, способ ускорить цикл — обрабатывать меньше потоков за раз. Также рекомендуется не обрабатывать один поток одним человеком.

Я думаю, что это распространенная и широко распространенная проблема — обрабатывать слишком много историй одновременно и надеяться, что это ускорит работу. Это не. Это приведет к разделению вашей команды на отдельных разработчиков, каждый из которых занимается своим делом.

Проблема 1 : Ваши разработчики в одной команде? Если да, то почему специалист по бэкэнду должен спрашивать вас о том, что сделал iOS-разработчик? Есть ли у них общая цель? Они должны попытаться выполнить свою общую цель вместе. Если потом они обнаружат, что что-то не ясно, и им потребуется обратная связь от PO, им следует обратиться к вам. Вместе.

Проблема 2 : см. комментарий к цели 1 и 2. Если все работают над разными частями чего-то, у вас на самом деле нет настройки команды. У нас также есть одна команда , которая делает это таким образом, не имея командной работы и создавая технический отдел, потому что им нужно быть «быстрыми».

Выпуск 3 : Да, также отсутствует командный дух. Это похоже на типичную ресторанную проблему. Сервис и повара не работают вместе, в худшем случае ведут свои маленькие войны и выясняют, кто виноват, и перекладывают работу на другую сторону.

Я надеюсь, что мои комментарии ясно показывают, что разделение команды — это не решение. Из того, что вы описываете, я не могу дать вам простое решение. Обычно разработчики iOS и бэкенда должны посвятить себя истории вместе. И если они этого не достигают, оба вместе терпят неудачу.

Более того, если ваша работа разделена так, что каждый делает свою маленькую историю, это также может быть проблемой личных симпатий и антипатий. После некоторого раунда нагнетания чувства вины люди становятся предвзятыми друг к другу. Ситуация усугубляется, если одни и те же люди снова и снова обсуждают одну и ту же тему.

Спасибо за ваш ответ. Я полагаю, мне любопытно: если у нас есть 8 разработчиков, и они не работают коллективно над 2 или 3 вертикальными срезами, а работают только над одной функцией, как это будет работать?
@djt Это зависит от реализуемой функции. В некоторых ситуациях имеет смысл работать с 2-3 срезами. Но по возможности команда должна сконцентрироваться на одной фиче (у которой может быть несколько историй). Я хочу сказать, что работа над разными срезами может иметь смысл, но не должна быть целью.
Стартап — пора разделиться на две команды?
СпросиСетьПолитика конфиденциальности1y, 0v