Все понимают, что для работы над продуктом, особенно в 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'ом полей в красивом интерфейсе можно сконфигурировать запрос за данными и получить отчет в нужном виде. И в этом случае «программировать» – это про умение разбираться в структуре данных, критическое отношение к получаемой информации и желание докопаться до самых-самых глубин своего продукта самому. Однако, чем более большим проектом надо руководить, тем больше технических знаний может пригодиться. Менеджеру может потребоваться оценить предложенную разработчиками архитектуру проекта, следить за наличием тестов для всех компонент, предложить, что нужно рефакторить. Хорошие менеджеры могут до бесконечности развивать технические знания и погружаться в устройство своего продукта. Честь и хвала таким менеджерам.
Комментарии (25)
jetcar
04.04.2018 12:08+1чтобы писать технические задания нужно уметь программировать, чтоб менеджить то не надо
habradante
04.04.2018 13:04+2«Менеджеру может потребоваться оценить предложенную разработчиками архитектуру проекта,»
Не может, иначе он не менеджер, а тим/тех лид. Не задача менеджера оценивать архитектуру.
" следить за наличием тестов для всех компонент,"
Это НЕ задача менеджера, максимум — тим лида.
" предложить, что нужно рефакторить."
… А затем самому залезть в код и показать как надо. «1000 и 1 ошибка начинающего менеджера или как заманаться и заманать остальных»
" Хорошие менеджеры могут до бесконечности развивать технические знания и погружаться в устройство своего продукта."
Хорошие менеджеры учатся руководить и помогать команде делать проект, и развивают они совсем другие навыки.
" Честь и хвала таким менеджерам."
Нет, они занимаются не своим делом.gz0t
04.04.2018 19:27Задача менеджера реализовать продукт с той командой, которая у него есть. Конечно, в процессе можно поменять разработчиков и тимлидов и найти компетентных, но это потом. В связи с этим могут возникать проблемы, которые описаны в статье. А именно оценить/отследить/заманать. Понимание внутренних процессов это огромный плюс. Это необходимо хотя бы для того, чтобы грамотно заменить команду. Или это тоже не задача менеджера, а максимум hr?
habradante
05.04.2018 11:02Понимание процесса != умение программировать. Задача менеджера выстроить процесс так, чтобы не затыкать собой дырки.
AlexTOPMAN
06.04.2018 21:07При постановке задачи менеджером нередко может возникнуть ситуация, когда без некоторых деталей программирования (т.е. нюансов той специализации которой менеджер управляет) задача правильно понята не будет. И не понимающий в программировании менеджер (читаем как «не умеющий в специализацию») эту проблему решить не сможет. Поэтому, по сравнению с «умеющим» такой всегда будет «недоменеджером». А вот будет ли наличие недоменеджера критичным — вопрос уже совсем другой…
Marui
04.04.2018 21:30+1Хорошие менеджеры учатся руководить и помогать команде делать проект, и развивают они совсем другие навыки.
Расскажите, что значит эта фраза? Только не нужно говорить «Спросить сколько делать ту или иную фичу. Поставить эстимацию. Перетащить таск в трелло. Ждать следующее собрание.»
Для меня менеджер должен:
знать 1-2 иностранных языка на хорошем уровне
владеть средствами ведения проекта, джира, трелло
владеть навыками общения с начальством и заказчиками, убеждать
очень хорошо владеть предметной областью для свободного общения с разработчиками, QA, другими менеджерами, начальством
принимать решения и разруливать конфликтные ситуации в коллективе и на проекте
обладать навыками тестирования и использования фреимворков тестирования в конкретной предметной области
быть готовым помогать программистам чем может, вплоть до «я найду тебе человека» и найти
Тоесть не важно кто это. ex-Lead QA или ex-Lead Programmer
Это сможет сделать ноунейм с улицы???
nanshakov
04.04.2018 22:37+1Согласен с вами кроме пункта про: обладать навыками тестирования и использования фреимворков тестирования в конкретной предметной области. Можете привести кейс?
Marui
04.04.2018 22:57Все ушли, а сервера с тестами падают. Менеджер может либо пофиксить сам, либо прийти завтра и с утра начать решать проблему.
kir_vesp
05.04.2018 08:49Если подобное критично, то менеджер должен достучаться до ответственного и проконтролировать исправление ситуации, помогая при необходимости. Если же нет, то это может подождать и до утра.
Marui
05.04.2018 10:06достучаться до ответственного и проконтролировать исправление ситуации, помогая при необходимости
Тоесть менеджер это такой безрукий достучала? Мне гроб, пожалуйста. Удачи в догонянии гуглов и масков с такими менеджерами.habradante
05.04.2018 11:08Да, менеджер «безрукий достучала». Потому что он может быть не в курсе тонкостей настройки, не в курсе последних коммитов, не в курсе точечных изменений которые привели к падению сервера. И он полезет самостоятельно менять что-то на проде? После такого чинить придется больше, намного больше.
А вот организовать саппорт, на такой случай, это вполне задача менеджера. И лучше, если саппорт будет организован заранее.
u440
06.04.2018 14:12Именно!
Задача менеджера предусмотреть подобные ситуации и «организовать пути отхода».
Безусловно просто отлично, если менеджер ещё и разбирается в предметной области. Но для его основных скилов это не всегда важно.
bzq
05.04.2018 14:53+2Странно. Для меня менеджер — это человек, который организует работу. Зачем тут нужно два иностранных языка? Вот уметь говорить с подчинёнными на понятном им языек — это да, это важно. Но это скорее всего будет не один-два и не факт, что иностранных…
PS Что-то похоже Вам хороших менеджеров пока не попадалось.
Druu
06.04.2018 07:18> Нет, они занимаются не своим делом.
прошу прощения, а в чем тогда дело менеджера? По-вашему, он ничем заниматься не должен, выходит? Зачем он тогда нужен?
acmnu
06.04.2018 10:17Задача нормального менеджера это коммуникация, стандартизация и оргазниция труда ввереного подразделения. Собственно изначальный смысл этого слова: управленец. Это потом появились разные менеджеры по продаже туалетной бумаги. Но в IT, обычно, именно управленцев то и не хватает.
— И сколько же у тебя людей-то в подчинении?
— Почти 3 тыс.
— Батюшки! Как же ты с ними справляешься? Трудно небось?
— Трудно с тремя, а когда трёх научишься организовывать, дальше число уже не имеет значения.Он не должен вообще уметь в компьютер. Он должен правильно распределить обязанности и недопускать бардака.
Druu
07.04.2018 03:48> Задача нормального менеджера это коммуникация, стандартизация и оргазниция труда ввереного подразделения.
Это замечательно, но хотелось бы конкретики. Вот выше описаны _конкретные_ вещи, которые менеджер не должен делать. А хотелось бы услышать конкретные, которые _должен_. Вот пришел менеджер Вася на работу и....?
> Трудно с тремя, а когда трёх научишься организовывать, дальше число уже не имеет значения.
Лучший способ организовать трех людей — сделать вид, что тебя нет. Не думаю, что этот способ скалируется на 3к.
it_manager
04.04.2018 15:44Такая неожиданная статья, ещё и от Яндекса. Напугала даже как-то. Точно менеджеры имеются в виду, а не тех. лиды и архитекторы?
nemavasi
04.04.2018 15:45Ну так то не помешало бы менеджеру годик хотя бы поработать прогером. Чтоб уже совсем то глупости не пороть. Хотя бы про наличие тестов в проекте сможет спросить.
jetcar
05.04.2018 09:29видел я таких недопрограммистов-менеджеров хорошо если они понимают что неумеют программировать, а если нет…
чтоб не спрашивать про тесты надо иметь лида хорошего, если такого нет и все джуниоры то ожидать что там будет всё хорошо нет смысла хоть, надо чтоб был лид делал ревью того что понаписали если этим будет заниматься менеджер причём он должен и сам писать а не только знать абстрактные правила написания кода, то у него не будет времени на менеджерскую работу которую тоже нужно делать
elegorod
04.04.2018 22:21редактировать файлы при помощи Vim
Это даже для программиста хардкор, не говоря уже про менеджера. Обычно достаточно скопировать файл с сервера, отредактировать и залить на сервер обратно.
Менеджеру может потребоваться оценить предложенную разработчиками архитектуру проекта
А это уже может сыграть медвежью услугу. Например, если менеджер знает только монолит с SQL базой, а команда делает микросервисы на NoSQL с событийно-ориентированной архитектурой. Это всё работает по другим принципам, и если менеджер начнёт требовать делать «так, как раньше», то хорошим это не кончится. Зависит от человека.
предложить, что нужно рефакторить
Тут явно перебор.
Fandorin
05.04.2018 11:20Менеджер не должен влезать в зону ответственности разработчиков, тестировщиков, аналитиков и тд.
Его задача — это организовать работу над проектом, найти нужных специалистов и держать все под контролем.
acmnu
05.04.2018 11:23Жесть. Мы возьмем человека предрасположенного к гуманитарным дисциплинам и работе с людьми, доведем его технические знания до уровня джуниора и поставим руководить проектом…
Менеджеру может потребоваться оценить предложенную разработчиками архитектуру проекта, следить за наличием тестов для всех компонент, предложить, что нужно рефакторить.
Почему ему это может потребоваться? Для этого в команде должен быть высококласный технический персонал. Или сказываются зарплаты ниже рынка и таких людей в компании очень мало?
strangeraven
06.04.2018 10:08Охх…
Статью следовало бы назвать "Типичные ошибки бывшего программиста, ставшего начинающим руководителем".
Конечно, это неплохо, если менеджер умеет программировать и говорит с программистами на одном языке. Также, неплохо если он понимает в дизайне и может поговорить на одном языке с дизайнером. Ну и понимание маркетинга — куда ж без этого, ведь продукт мало разработать, его ещё надо продать. А если руководитель окончил консерваторию по классу гитары и может душевно спеть на вечеринке, сплотив коллектив в одну дружную семью — это вообще отлично.
Но в целом основные задачи у руководителя всё-таки другие. А задачи по большому счету две: продукт и команда.
Менеджер должен уметь редактировать файлы при помощи Vim??? :/ Да вы наверное шутите.
bzq
06.04.2018 14:39Что-то у меня чешутся руки написать, что если менеджер должен уметь программировать, то наверное и программист должен уметь менеджерить. Как-то набрать и организовать команду, придумать продукт, продать его заказчику, согласовать план работ, получить оплату, свести бюджеты, следить за рисками, замотивировать всех вокруг. Для симметрии вроде как просится…
(Тут должны быть смайлики, а то без них в интернете шутки уже давно не понимают)
werklop
Хорошо жить вот в таких розовых мечтах, наверное