На прошлой неделе стартовал уже седьмой набор в Школу менеджеров Яндекса. В этот раз мы решили дополнить программу техническими лекциями и впервые добавили в тестовое задание технический вопрос. В этом посте я поделюсь своим мнением о том, почему без умения программировать менеджеру будет сложнее знать и развивать свой продукт.
Все понимают, что для работы над продуктом, особенно в IT, знания технологий так или иначе необходимы. Для менеджера не должны быть новыми слова «бэкенд», «верстка», «база данных». Чтобы отлавливать баги или видеть точки роста в продукте, нужно не просто постоянно им пользоваться, но и понимать, как он устроен. К разработчикам лучше приходить с формулировками «на мобильном интернете долго отдаётся вёрстка» или «при таком сценарии не загружается часть данных», а не говорить «вот тут что-то тормозит, посмотри». Таким образом менеджер перекладывает генерацию и проверку гипотез о том, что же происходит в проблемном месте, на разработчика, у которого «такая же точно нога, но не болит».
Если же менеджер, например, при воспроизведении проблемы открыл браузерную консоль, увидел в ней сетевые ошибки и пришел к разработчику с данными из трейсов этих ошибок, или сам заглянул в данные и увидел, что бэкенд отдал некорректный json, ситуация сразу начинает выглядеть как подкрепленная доказательствами проблема, а не просто жалоба единичного пользователя.
Похожая ситуация складывается и с умением программировать. Представим, что есть менеджер, который примерно соответствует всем пунктам из прошлого поста, но совсем не умеет программировать. Как этот человек воспринимается остальной командой?
Такой менеджер воспринимается членами команды, как постоянный генератор дополнительной и иногда бесполезной работы для них. И тут умение программировать может помочь менеджеру более эффективно организовывать свою работу и работу команды.
Умея программировать, можно быстро проверять свои же гипотезы, не полагаясь на чужие вычисления и не отвлекая людей заказами этих вычислений. Можно самостоятельно посчитать, сколько пользователей видели фичу Х, или собрать какую-то статистику для презентации. Многие программисты не любят переключать контексты, а просьбы менеджера «быстренько прикинуть» что-то по данным отвлекают и могут «сбить настрой на работу» на продолжительное время. Менеджер, который может «быстренько прикинуть» сам, будет меньше дёргать свою команду, повышая этим её производительность. То, что называется продуктовым видением, должно быть подеркплено качественными и количественными исследованиями. И счастливая та команда, в которой менеджер умеет проводить хотя бы простые количественные замеры самостоятельно.
Кроме того, умение программировать помогает валидировать расчеты, которые приносят аналитики. Если, например, менеджер попросил посчитать долю запросов с каким-то сложным набором действий на них, и аналитик приносит расчет, в котором просто общее количество запросов не сходится с собственным расчетом менеджера, у него есть повод усомниться в правильности расчетов и аргументированно попросить перепроверить.
Даже самое базовое умение программировать иногда очень помогает говорить с разработчиками на одном языке. Это как минимум добавляет менеджеру «кармы» среди разработчиков, ведь как он может ставить им задачи, если вообще не понимает, чем они занимаются? Если разработчик говорит, что нужно взять неделю на рефакторинг, а менеджер не понимает, зачем это нужно, и торопит его с фичами, и потом у разработчика образуется огромный техдолг, от этого может пострадать весь проект.
Еще это может помогать при планировании, потому что позволяет лучше понимать трудоемкость задачи, и если разработчики говорят, что тут разработки на три дня, а менеджер понимает, что он бы за день сделал, то можно более адекватно оценивать сроки и не бояться оспаривать озвученные разработкой варианты.
В любой специальности ценятся крутые самодостаточные специалисты. При прочих равных программиста с развитыми soft skills будут предпочитать программисту-интроверту, также как менеджер, умеющий программировать и имеющий технический бекграунд, в технологических компаниях будет цениться выше, чем просто хороший менеджер.
Многие рабочие файлы, скрипты и некоторые данные лежат на серверах с консольным доступом по ssh, поэтому нужно уметь дружить с командной строкой для работы с ними. Интерфейс взаимодействия через командную строку есть и в unix-подобных системах (Linux, MacOS), и в Windows.
Если вы раньше не работали в командной строке, то начать знакомство можно с прочтения, например, статьи «Основы линукс: Введение в bash».
Конкретные ссылки я привожу лишь в качестве примеров. Хочется, чтобы в итоге вы имели представление о том, как:
Зачастую файлы с данными имеют очень большой размер и для работы с ними не получится использовать, например, привычных многим из вас Excel. Поэтому стоит познакомиться с командами для работы с текстовыми файлами:
Будет полезно, если в итоге у вас сложится представление о следующих командах: cat, sort, uniq, wc, head, tail, awk, sed, grep, join.
Очень полезно хорошо знать команду grep с использованием регулярных выражений:
Более мощным и гибким инструментом для работы с данными является Python. Для того чтобы овладеть им, подойдет любой онлайн курс, можно начать с codecademy. 10 minutes to pandas – для тех, кто хочет легко и быстро анализировать данные.
В завершение хочется уточнить, что умение программировать для менеджера – это не десятки прочитанных книг по питону или плюсам, не тысячи строк закоммиченного кода (хотя от такого менеджера скорее всего никто не откажется!). Во многих компаниях имеются уже готовые инструменты, где на sql-like языке, или вообще drag-and-drop'ом полей в красивом интерфейсе можно сконфигурировать запрос за данными и получить отчет в нужном виде. И в этом случае «программировать» – это про умение разбираться в структуре данных, критическое отношение к получаемой информации и желание докопаться до самых-самых глубин своего продукта самому. Однако, чем более большим проектом надо руководить, тем больше технических знаний может пригодиться. Менеджеру может потребоваться оценить предложенную разработчиками архитектуру проекта, следить за наличием тестов для всех компонент, предложить, что нужно рефакторить. Хорошие менеджеры могут до бесконечности развивать технические знания и погружаться в устройство своего продукта. Честь и хвала таким менеджерам.
Все понимают, что для работы над продуктом, особенно в IT, знания технологий так или иначе необходимы. Для менеджера не должны быть новыми слова «бэкенд», «верстка», «база данных». Чтобы отлавливать баги или видеть точки роста в продукте, нужно не просто постоянно им пользоваться, но и понимать, как он устроен. К разработчикам лучше приходить с формулировками «на мобильном интернете долго отдаётся вёрстка» или «при таком сценарии не загружается часть данных», а не говорить «вот тут что-то тормозит, посмотри». Таким образом менеджер перекладывает генерацию и проверку гипотез о том, что же происходит в проблемном месте, на разработчика, у которого «такая же точно нога, но не болит».
Если же менеджер, например, при воспроизведении проблемы открыл браузерную консоль, увидел в ней сетевые ошибки и пришел к разработчику с данными из трейсов этих ошибок, или сам заглянул в данные и увидел, что бэкенд отдал некорректный json, ситуация сразу начинает выглядеть как подкрепленная доказательствами проблема, а не просто жалоба единичного пользователя.
Похожая ситуация складывается и с умением программировать. Представим, что есть менеджер, который примерно соответствует всем пунктам из прошлого поста, но совсем не умеет программировать. Как этот человек воспринимается остальной командой?
- Привет, я думаю, что надо запилить офигенную фичу A (B,C,D,...), хочу проверить, насколько она будет востребована. Обсчитай, мне, пожалуйста, какова доля таких-то сценариев в использовании нашего продукта?
- Привет, у меня периодически криво отрисовывается страница, если пользователи тоже это видят, это просто позор. Проверь, что происходит?
- Привет, у меня тут в АБ эксперименте статистически значимо меняется метрика, давай поймем, почему?
- Привет, я тут пишу пост о нашем новом внедрении, проверь, пожалуйста, правильно ли я описал детали реализации.
- ...
Такой менеджер воспринимается членами команды, как постоянный генератор дополнительной и иногда бесполезной работы для них. И тут умение программировать может помочь менеджеру более эффективно организовывать свою работу и работу команды.
Умея программировать, можно быстро проверять свои же гипотезы, не полагаясь на чужие вычисления и не отвлекая людей заказами этих вычислений. Можно самостоятельно посчитать, сколько пользователей видели фичу Х, или собрать какую-то статистику для презентации. Многие программисты не любят переключать контексты, а просьбы менеджера «быстренько прикинуть» что-то по данным отвлекают и могут «сбить настрой на работу» на продолжительное время. Менеджер, который может «быстренько прикинуть» сам, будет меньше дёргать свою команду, повышая этим её производительность. То, что называется продуктовым видением, должно быть подеркплено качественными и количественными исследованиями. И счастливая та команда, в которой менеджер умеет проводить хотя бы простые количественные замеры самостоятельно.
Кроме того, умение программировать помогает валидировать расчеты, которые приносят аналитики. Если, например, менеджер попросил посчитать долю запросов с каким-то сложным набором действий на них, и аналитик приносит расчет, в котором просто общее количество запросов не сходится с собственным расчетом менеджера, у него есть повод усомниться в правильности расчетов и аргументированно попросить перепроверить.
Даже самое базовое умение программировать иногда очень помогает говорить с разработчиками на одном языке. Это как минимум добавляет менеджеру «кармы» среди разработчиков, ведь как он может ставить им задачи, если вообще не понимает, чем они занимаются? Если разработчик говорит, что нужно взять неделю на рефакторинг, а менеджер не понимает, зачем это нужно, и торопит его с фичами, и потом у разработчика образуется огромный техдолг, от этого может пострадать весь проект.
Еще это может помогать при планировании, потому что позволяет лучше понимать трудоемкость задачи, и если разработчики говорят, что тут разработки на три дня, а менеджер понимает, что он бы за день сделал, то можно более адекватно оценивать сроки и не бояться оспаривать озвученные разработкой варианты.
В любой специальности ценятся крутые самодостаточные специалисты. При прочих равных программиста с развитыми soft skills будут предпочитать программисту-интроверту, также как менеджер, умеющий программировать и имеющий технический бекграунд, в технологических компаниях будет цениться выше, чем просто хороший менеджер.
С чего можно начать?
Многие рабочие файлы, скрипты и некоторые данные лежат на серверах с консольным доступом по ssh, поэтому нужно уметь дружить с командной строкой для работы с ними. Интерфейс взаимодействия через командную строку есть и в unix-подобных системах (Linux, MacOS), и в Windows.
Если вы раньше не работали в командной строке, то начать знакомство можно с прочтения, например, статьи «Основы линукс: Введение в bash».
Конкретные ссылки я привожу лишь в качестве примеров. Хочется, чтобы в итоге вы имели представление о том, как:
- навигироваться по файловому дереву
- создавать, копировать и удалять файлы
- редактировать файлы при помощи Vim или nano
- с помощью ssh и scp обмениваться любым файлом с ноутбука на сервер и обратно.
Зачастую файлы с данными имеют очень большой размер и для работы с ними не получится использовать, например, привычных многим из вас Excel. Поэтому стоит познакомиться с командами для работы с текстовыми файлами:
Будет полезно, если в итоге у вас сложится представление о следующих командах: cat, sort, uniq, wc, head, tail, awk, sed, grep, join.
Очень полезно хорошо знать команду grep с использованием регулярных выражений:
- Регулярные выражения для новичков
- Использование grep и регулярных выражений для поиска текстовых шаблонов в linux.
Более мощным и гибким инструментом для работы с данными является Python. Для того чтобы овладеть им, подойдет любой онлайн курс, можно начать с codecademy. 10 minutes to pandas – для тех, кто хочет легко и быстро анализировать данные.
В завершение хочется уточнить, что умение программировать для менеджера – это не десятки прочитанных книг по питону или плюсам, не тысячи строк закоммиченного кода (хотя от такого менеджера скорее всего никто не откажется!). Во многих компаниях имеются уже готовые инструменты, где на sql-like языке, или вообще drag-and-drop'ом полей в красивом интерфейсе можно сконфигурировать запрос за данными и получить отчет в нужном виде. И в этом случае «программировать» – это про умение разбираться в структуре данных, критическое отношение к получаемой информации и желание докопаться до самых-самых глубин своего продукта самому. Однако, чем более большим проектом надо руководить, тем больше технических знаний может пригодиться. Менеджеру может потребоваться оценить предложенную разработчиками архитектуру проекта, следить за наличием тестов для всех компонент, предложить, что нужно рефакторить. Хорошие менеджеры могут до бесконечности развивать технические знания и погружаться в устройство своего продукта. Честь и хвала таким менеджерам.
