Чтение онлайн

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

Вот несколько тревожных сигналов, которые могут свидетельствовать о том, что на топологию следует обратить внимание:

• Вы постоянно перебрасываете разработчиков из одной команды в другую.

• Вы часто вынуждены вмешиваться, чтобы урегулировать конфликты, связанные с зависимостью команд друг от друга.

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

• Команды обладают слишком ограниченным объемом ответственности.

• Разработчики должны иметь дело со слишком большим количеством сложности во многих областях.

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

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

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

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

Топология определяет, с кем люди работают на повседневной основе, над чем они трудятся и как взаимодействуют между собой. Ее изменение может привести к крайне деструктивным последствиям.

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

Я впервые встретил Дебби в компании Netscape, где она руководила инжиниринговой организацией, отвечающей за Netscape Browser. Она пришла в Netscape в результате приобретения платформы Collabra в 1995 году. Возможно, вы ничего не слышали о Collabra, но это была необыкновенная команда с очень сильными лидерами, которые быстро стали играть ключевую роль в беспрецедентном росте компании Netscape.

Дебби родом из Среднего Запада, изучала математику и информатику в Мичиганском университете. Затем переехала в Кремниевую долину, продолжила изучение информатики в Стэнфордском университете, стала разработчиком программного обеспечения, а вскоре начала занимать лидерские позиции в сфере инжиниринга в одной крупной компании за другой.

В Netscape Дебби завоевала репутацию одного из ведущих лидеров в сфере инжиниринга в нашей отрасли, потом работала с рядом венчурных компаний и отраслевыми партнерами и стала известна как человек, которого зовут, чтобы существенно или срочно повысить качество работы инжиниринговой организации.

Дебби приходит в компании, преимущественно в стартапы с многообещающими бизнес-возможностями, когда они нуждаются в масштабировании инжиниринга или когда инженеры по разным причинам испытывают трудности с эффективным созданием продуктов и их выводом их на рынок. На текущий момент она помогла таким образом более чем 50 компаниям, многие из которых сейчас очень успешны.

Часто Дебби застает в компании расстроенных руководителей и несчастных инженеров, доверие между которыми подорвано и которые работают исключительно с функциональными командами и дорожными картами. Ее цель — завоевать доверие этих талантливых профессионалов, вовлечь их в решение общей задачи и трансформировать организацию, собрав эффективные, масштабируемые продуктовые команды.

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

Я попросил Дебби рассказать, каким образом ей удается с подобным постоянством трансформировать инжиниринговые организации.

Вот как она говорит об этом:

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

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

Все начинается сверху

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

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

Я вижу также, что многие основатели и CEO не понимают роли, которую сами они играют в проблемах и успехах инжиниринговой организации. Так что здесь необходима просветительская работа.

Фокус внимания и стратегия

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

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