Работа в технологических компаниях — моя страсть. Это динамичная среда, в которой вы никогда не прекращаете учиться и где вы имеете дело с интересными людьми со всего мира. Но иногда это может быть проблемой и даже разочарованием. Генеральный директор хочет доставить, убедить своих инвесторов, завоевать клиентов, иметь отличную культуру и, конечно же, быть быстрее конкурентов. Технический персонал хочет прежде всего одного: отличный продукт.

Теоретически они оба хотят одного и того же. Но это все же что-то другое. Так в чем же причины, по которым бизнес и технологии так плохо ладят? Зачем нам нужен технический руководитель, который прежде всего делает одно: переводит? Стефан Бахофен, опытный технический директор и технический консультант, и я решили объединиться в этом деле и ответить на некоторые из наиболее важных вопросов, которые есть у обеих сторон.

Стефан: Вы работали генеральным директором в различных технологических компаниях. Испытывали ли вы когда-нибудь трудности в общении с инженерами?

Борис: Должен признаться, что я довольно регулярно сталкивался с коммуникативным разрывом в компаниях, которые я основал или в которых работал генеральным директором. Однако мне каким-то образом удалось приучить себя общаться с инженерами и — что более важно — уважать их мнение. Особенно когда дело доходит до сроков и всего того, о чем я не знаю. Не поймите меня неправильно. Мне нравится работать в технологической среде, и я люблю работать с инженерами, специалистами по обработке данных, QA и CTO. НО: такое сотрудничество работает только на основе доверия, и как генеральный директор вы обучены сводить неопределенность к минимуму. Как это может работать лучше всего, Стефан?

Слушая и уважая наше мнение. Допущение экспериментов и неудач делает его безопасным местом для работы.

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

Борис: Я всегда считал точное время самым важным вопросом. Вам нужно знать, когда вы выпускаете что-то, так как ваша маркетинговая команда ждет или у вас заканчиваются средства. Почему так сложно оценить проект?

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

Стефан: Это не только сложно. Оценить почти невозможно. Мы продолжаем просить об этом, мы продолжаем это делать и продолжаем терпеть неудачи. Мне нравится указывать на два источника, о которых я знаю, которые объясняют это более подробно и красноречиво, чем я могу:

1) книга «Факты и заблуждения программной инженерии» Роберта Л. Гласса и

2) презентация Джозефа Пелрина «Психология оценивания».

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

Я полагаю, это не поможет вам с вашими маркетологами, которые сидят на заборе и ждут, пока мы, инженеры, решим проблему?

Борис: Нет!

Стефан: Я так и думал. Но я рад, что ты все еще слушаешь. Есть и другие способы сделать доставку предсказуемой — вместо оценки — и, в конечном счете, помочь вам в планировании. Сосредоточьтесь на процессе создания ценности и команде. Защитите команду от отвлекающих факторов и обеспечьте себе множество моментов потока. Иметь сильное обеспечение качества. Выровняйте всю команду по приоритету. ПОЦЕЛУЙ — будь проще и глупее. Обеспечьте эмоциональную безопасность. Поощряйте обучающуюся организацию. Не оптимизируйте затраты на одного разработчика. Платить разработчику в 10 раз лучше, чем в среднем, в два раза больше, чем в среднем, — это отличное соотношение цены и качества для вас.

Борис:Стефан, вы когда-нибудь слышали что-то вроде: «Почему это всегда так долго? Это просто приложение, верно?» или «Зачем нам столько инженеров? Это все еще просто приложение». Какова ваша реакция?

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

Борис: Это здорово. У меня для вас есть еще цитаты: «У нас так много инженеров — почему они до сих пор производят баги?» или «Что за хрень? Зачем нам команда QA? Ребята, вы не можете написать правильный код?»

Стефан:Причин, по которым вас не устраивает качество, может быть много. Но сначала о QA: QA обучены находить ошибки. Но не только это. QA напишет вам план тестирования. Это привносит строгость в тестирование. Затем каждая функция, вероятно, имеет несколько тестов. Не только для того, чтобы убедиться, что он работает, но и для того, чтобы он корректно давал сбой, когда происходит что-то неожиданное, часто не указанное. QA также сообразительны в использовании инструментов для автоматизации этих тестов. Автоматизированные тесты позволяют вам выпускать релизы часто без больших затрат. Это относится к регрессиям. К сожалению, не так уж редко изменение кода влияет на другие, явно не связанные функции в другом месте кода. QA также проверяет, чтобы требование было реализовано должным образом. Лучшей практикой является дополнительная пара глаз, чтобы проверить, все ли сделано так, как задумано. Мы применяем это и в других областях. Подпись надвое, аудит, вычитка статьи перед публикацией и т. д. Если у вас все еще слишком много ошибок: Были ли сроки реалистичными? Характеристики хорошие? Могут ли разработчики работать бесперебойно? У вас слишком много технической глубины в критических компонентах?

Борис:Что бы вы посоветовали при найме инженеров?

Стефан:Чтобы привлечь их в первую очередь? Иметь демонстративно отличные и подходящие условия работы, включая офис, оборудование и высокую культуру труда. А-игроки хотят продолжать учиться, вовлекать себя и иметь цель. Для скрининга: обратите внимание на отношение и передаваемые навыки. Работайте с ними, чтобы решить конкретную проблему.

Борис: В чем секрет успешной технологической компании?

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

Стефан:Хорошее руководство! Возможно, там даже меньше терпимости к плохому или посредственному руководству для достижения отличных, устойчивых и рентабельных результатов, чем в других компаниях и секторах — хорошая команда без эгоизма. Позвольте технической команде встретиться с вами на уровне глаз, в том числе в отношении проектирования организации. Убедитесь, что у вас есть необходимые технические знания внутри компании. Держите продукт простым. Имейте четкий приоритет.

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

Борис: О да. Звучит знакомо. Существует размытая грань между прототипом и готовым к производству, верно? То, что мы внутренне считаем прототипом или MVP, может быть ценным и конечным продуктом для клиента. И ТЫ ДЕЙСТВИТЕЛЬНО СКАЗАЛ "ЭТО ТОЛЬКО ПРОТОТИП"??? Я просто шучу. Тем не менее, сообщение об ошибках не является неправильным, и это больше касается того, как это делается. Предположим, вы знаете, что мелкие ошибки не имеют значения на данном этапе, а затем помещаете их куда-нибудь в бэклог. Я согласен с тем, что это головная боль, когда отдел маркетинга или инвестор настаивают на немедленном исправлении того, что их лично беспокоит. На этом раннем, экспериментальном этапе все сводится к тому, чтобы научиться улучшать продукт, чтобы он соответствовал потребностям клиента.

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

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

Борис:Отличный вопрос! Честно говоря, я думаю, что тема ценностного предложения — это вызов. Я использую экспериментальные подходы для проверки ценностного предложения. Это означает, что версия, создающая наибольший спрос, побеждает, и это может привести к результату, отличному от ожидаемого, в зависимости от восприятия клиента. Но я думаю, что проблема заключается скорее в непонимании ценностного предложения и попытках проявить излишнюю креативность. Я видел много компаний, в которых разные отделы и отдельные лица по-разному оценивали ценность продукта. Когда вы слышите их объяснения, вы думаете, что они говорят о разных продуктах. Крайне важно обучить команду и согласовать суть продукта.

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

Борис: Ну, я думаю, что компания, производящая технологические продукты, должна строиться вокруг ядра, то есть команды разработчиков и разработчиков. Продавец — это прямая связь с покупателем, и информация должна передаваться туда и обратно. Итак, чтобы ответить на ваш вопрос: ДА! Команде нужен общий язык. НО: это может зайти слишком далеко. Продавцы немного другие, но, например, для маркетологов не всегда полезно следить за всем, что происходит в процессе разработки. В конце концов, пользователи в большинстве случаев также будут знать очень мало технической информации, и сообщения должны в основном волновать их о преимуществах.

Стефан:Я часто задаю себе один вопрос: как рано технологическая компания должна нанять менеджера по продукту? Как вы относитесь к назначению менеджера по продукту почти одновременно или вскоре после технического директора (после того, как прототип готов), а позже — остальных, таких как маркетинг, продажи и т. д.?

Борис: Теоретически да. Но обычно есть ограничения. Я полагаю, вы говорите о стартапе, верно? В этом случае вам нужно мудро выбрать, кого нанять в первую очередь. Мне нравится стратегический подход, определяющий сначала цели, а затем необходимые внутренние компетенции. Это означает, что если вы хотите достичь определенной цели за определенное время, вам нужно развить определенные компетенции, чтобы достичь ее. В случае технологической компании важной компетенцией будет понимание потребностей клиентов и их реализация. Чья это роль? На самом деле… извините, Стефан, но я бы даже нанял менеджера по продукту до технического директора — или технического соучредителя.

Стефан: Хорошо. Пока мы здесь: Нужен ли нам финансовый директор уже сейчас? Они дорогие, и я мог бы использовать эти деньги, чтобы строить вещи.

Борис:Нет, я не думаю, что вам изначально нужен финансовый директор. Обычно это более поздний найм, когда компания становится более зрелой. Однако мне нравится работать с финансовыми директорами, поскольку я плохо разбираюсь в цифрах. Дело не в том, что я не умею считать, но как генеральный директор вы должны быть оптимистом и постоянно продавать идею, услугу или продукт всем. Мотивировать команду и так далее. Финансовый директор играет противоположную роль с точки зрения цифр, и вы обычно встречаетесь где-то посередине. Но это будет уже совсем другой разговор…