Мнение компании RegionSoft Developer Studio может не совпадать с мнением сотрудника. А может и совпадать. Тексты свободного микрофона мы не исправляем и не согласуем.Привет, Хабр! Статья отчасти правильная, и она не просто задела меня и зацепила глаз, а буквально оттопталась по больным мозолям моей менеджерской души. В общем, 10 лет назад, придя работать в ИТ-сферу, я думала точно так же, как автор статьи. Расскажу о вилах, граблях и райских облаках такого подхода.
Путь: менеджер — инженер по тестированию — менеджер
Итак, в 2007 году я пришла работать в крупную телекоммуникационную компанию и мгновенно ощутила серьёзные проблемы в общении с программистами и подразделением АСУ (автоматизированных систем управления). Ребята по нашим ТЗ готовили нам выгрузки данных, которые мы обрабатывали в Excel и Access, а затем использовали для стандартных коммерческих нужд вроде рассылок, разработок нишевых тарифных планов и охоты за недобросовестными продавцами наших симчатых пакетов подключения. Программисты наши технические задания ненавидели — самым безобидным замечанием был вызов к себе и швыряние распечатанными листами со словами «хватит плодить сущности, пиши, что именно тебе надо, а не вот это всё». Мне было обидно, ведь каждое ТЗ я расписывала по-университетски старательно: кто заказчик, для каких целей, какие поля, даты, сроки, согласования и т.д.
Во время очередного обеда с разработчиками ко мне пришло осознание, что всё это оттого, что я никуда не гожусь со своим экономическим образованием и, чтобы научиться общаться с программистами, нужно… стать одним из них. Так я пошла в один корпоративный университет Нижнего Новгорода (привет, НИИТ!), где в течение двух лет на полном серьёзе осваивала: алгоритмы и структуры данных, С, С++, Java (хотелось застрелиться), Python (его полюбила нежно), немножко Assembler (а Java-то ничего) и даже UML-диаграммы и управление ИТ-проектами. У нас был гигантский и глубокий курс UNIX, в ходе которого я научилась работать с консолью, компилировать в gcc, grep-ать, писать регулярные выражения, познакомилась с vim и т.д. То есть стала прямо эталонным образцом из статьи — уже обросший опытом менеджер с навыками администрирования и знанием довольно глубоких основ программирования.
Мои технические задания изменились — они стали едва ли не готовыми скриптами для выборок и… разбесили АСУ-шников ещё больше. Что вышло?
- Появилась уверенность в своей правоте и избранности при том, что программисты были на голову опытнее. Грепающий менеджер, умеющий редактировать файлы в vim и немного секущий в SQL, стал головной болью семи человек.
- Навыки транслировались на совершенно другие системы. Например, моё знание Python никак не ложилось на недознание SQL.
- Я ощутимо выросла над коллегами-менеджерами, отчего возникало недопонимание. Зато отлично складывались отношения со службой безопасности — теперь я знала, что фрод отлавливается не с помощью магии, а с помощью скриптов, снятия, анализа и контроля трафика. Мы реализовывали интересные проекты, и там универсальность была впору.
- Точности расчёта времени и затрат на реализацию очередного проекта не прибавилось, поскольку одно дело всё спроектировать, а другое — реализовать. Пришлось вникать в тестирование и осознать, что UML-диаграммы ничего не решают. Некоторые разработчики о них и знать не знали, но фигачили код с бешеной скоростью и умели управлять своим временем внутри проекта, а другие знали всё, а кодили мало — просто не было навыков. Теоретики.
- Самое главное — понимание кода продуктов и кода, стоящего за услугами, не дало того углублённого знания продукта, которое появляется при непосредственном тесном взаимодействии с разработкой в роли пользователя. Тут дело такое: менеджер — это мостик между разработчиком и конечным пользователем. И, чтобы что-то улучшить, нужно понимать, чего не хватает клиенту и его сотрудникам, а не почему модуль отрабатывает за 0,15 мс, а не за 0,11 мс. Клянусь, пользователь этого не замечает. А вот то, что нет крестика, которым закрывают программу, очень даже замечает (реальный баг одного из релизов личного кабинета абонента).
В общем, я стала понимать, что быть менеджером не благородно и ушла в инженеры по тестированию в компанию-разработчика систем связи и коммутации. То есть что? Правильно — оказалась по другую сторону баррикад и теперь пришёл мой черёд психовать при виде менеджера проекта или, что ещё хуже, маркетолога или продажника. «Блокирующий баг от клиента», «Критикал от клиента», «Запрос на фичу, передаём в разработку» — о боже, эти люди вообще понимали, как мы работаем в поте лица и что нам не до новых фич?! Как можно было присвоить критикал минорному багу? Почему менеджеры проекта так некстати употребляют слова: бэклог, спринт, коммит, багтрекер, почему они путают Багзиллу и Мозиллу Файерфокс, что значит выражение «задевелопь фичу, чтобы я мог провести митинг с аккаунтом», ведь так не говорят? На самом деле, менеджеры всё понимали и даже сочувствовали нашим переработкам, но за их плечами стояло то, о чём пока ни я, ни автор исходной статьи не обмолвились.
За плечами менеджера стоят деньги. И вся программистская работа, работа тестировщика и инженера — это деньги компании, на которые она существует и из которых нам платят зарплату. И если менеджер в рабочее время «накидывает архитектурку» и копается в дампах из Wireshark, чтобы развернуться перед программистом во всей красе, он теряет эти самые деньги.
Правила менеджера-джедая
Как вы уже поняли, из инженеров по тестированию я вернулась в менеджеры, уже перерождённой и осознанной. Увы, я не могу рассказать о тонкостях управления проектами в RegionSoft Developer Studio, поскольку это закрытая разработка и внедрения, рассказ о которых нужно согласовывать с клиентами, но после такой двойной трансформации я с радостью поделюсь правилами, благодаря которым можно стать действительно успешным менеджером.
Продукт нужно знать на уровне кода (точнее, архитектуры), но не кодить его. Знание продукта от и до — первоочередной навык любого менеджера (проекта, продукта, по продажам, по маркетингу). Если вы не понимаете, как и для чего его можно использовать, не видите взаимосвязи модулей и сущностей, не осознаёте, на что повлияет изменение той или иной функциональности, вы никогда не сможете сделать продукт успешным на рынке. Глубокое понимание функционирования и принципов работы помогает менеджеру быть требовательным и опытным, но не сумасбродным внутренним заказчиком. Увы, пиарщики и маркетологи за редким исключением этого не понимают, так что вся надежда на нас.
Принцип прост: не предлагайте новые фичи только ради того, чтобы было; не списывайте у конкурента не глядя; не идите на поводу у безумных изменений клиента. Если вы знаете архитектуру продукта, вы никогда не скажете программисту: «Ну что тебе, трудно простенькую формочку прикрутить, заказчик говорит, дело двух часов». Просто потому что вы прекрасно понимаете, в каких местах вылезут изменения и насколько большая работа разработчиков и тестировщиков понадобится. Клянусь, легче отговорить от формочки заказчика.
Делайте свою работу, программисты и инженеры сделают свою сами. Уметь анализировать код, трафик, пользоваться отладчиком в браузере — прекрасные навыки для аналитической работы. Но на время общения с программистами оставляйте их при себе. Дело в том, что разработчики в любом случае проверят информацию и снимут свои дампы, заберут и проанализируют логи. И сделают это гораздо профессиональнее менеджера, который разобрался с информацией между делом.
Менеджер с навыками программирования (точнее проектирования и разработки ПО) — подарок судьбы. Менеджер, тратящий время на освоение командной строки и vim-a — неэффективная имитация.
Учитесь писать ТЗ и переводить с языка заказчика на язык задачи. Это очень важный скилл. Научитесь встать на сторону заказчика, проанализировать его требования, собрать их и оформить их во внятное техническое задание, которое можно будет согласовать, подписать и приступить к работе. Это опять тот блок деятельности менеджера, где он должен проявить своё понимание разработки и знание продукта. Описания должны соответствовать сущностям архитектуры, требования — не выходить за грани исполнимой реальности, цены и сроки — коррелировать с мощностью команды разработки с учётом всей загруженности. В обратном случае придётся договариваться об отсрочке дедлайна и работать в ущерб компании, а это не та цель, ради которой существует менеджер проекта.
Учитесь общаться с заказчиком. Чаще всего заказчики далеки от сферы разработки ПО и проектирования, им совершенно непонятно, почему нельзя добавить «крошечное окошко» или «небольшую фичу, недорого и недолго же» (ну, например, типа такого: привязать к системе считыватель номеров автомобиля на проходной, прописав логику распознавания марки по шильдику и распознования гос. номера). Менеджер — это буфер между желаниями заказчика и возможностями программиста, который умеет отсекать ненужные фантазии из требований. Хороший менеджер тщательно изучит бизнес заказчика, рассмотрит все требования и сумеет выделить те, которые действительно нужны, обосновать выбор и убедить клиента, что он сам так думает.
Планируйте внутри команды. Вообще план работы команды с горизонтом на месяц и больше — буквально главная шпаргалка менеджера. Ни одно решение не должно приниматься без анализа загруженности ресурсов. И только на первый взгляд кажется, что загрузку легко спрогнозировать. В тех же внедрениях CRM или любого другого ПО несколько человек заняты в нескольких проектах одновременно, и таких проектов бывает что на год вперёд. Важно не только расставить приоритеты, но и сделать это с учётом экономической целесообразности, критичности задачи, величины проекта. Ах да, и с учётом графика отпусков :-)
Учитесь понимать риски, видеть их и управлять ими. Хороший менеджер прогнозирует, анализирует и пресекает риск до того, как он стал риском. У менеджера должна быть целая система управления рисками — таблица, где перечислены потенциальные угрозы, маркеры рисков и пути реагирования. И здесь у менеджера возникает ещё одна головная боль — на риск может пойти руководитель, не особо интересуясь табличкой. Виновата в итоге всё равно будет команда, но быть готовым к такому раскладу определённо нужно.
Управляйте бюджетом. Бюджетов у проекта несколько: первый — это затраты на его реализацию, второй — затраты заказчика на покупку, третий — реальные затраты на реализацию. Если не управлять бюджетом, третий превратится в монстра, который сожрёт всю коммерческую выгоду. Поэтому менеджер должен точно знать точки экономии, заделы роста затрат, которые стоит контролировать, и понимать, как управлять всеми тремя аспектами, чтобы заказчик был доволен и компания оказалась в плюсе. Прогибы на скидку, штрафы за полдня просрочки и неосторожные условия договора — это всё о бюджете, поэтому не забывайте, что это ваша задача.
Умейте критически мыслить. У каждого менеджера должен быть набор характеристик проекта: цена, сроки, ресурсы, необходимые инструменты и т.д. При возникновении любого вопроса и любой проблемы стоит взвесить плюсы и минусы, понять степень влияния на всю задачу в целом. Например, если вам предложили использовать в разработке бета-версию новейшего фреймворка, как менеджер проекта вы не должны броситься читать все мануалы, но должны поразмыслить: насколько версия сырая, какая поддержка будет, сколько багов в любой бете и т.д. Хотя в этом примере речь скорее о тимлиде, но больно уж ситуация распространённая.
Чтобы сформировать критическое мышление, необходимо собрать для себя инструменты и подходы, которые позволят логически и системно анализировать изменение каждого фактора. Тогда и решения будут взвешенные, а не «WOW, погнали!»
Учитесь координировать команду по ситуации, а не по agile. Ваша компания может работать по agile, внедрять scrum и геймификацию, придерживаться канбан, но всё это рассыпается от первого же неадекватного, требовательного, а ещё лучше государственного заказчика, который покупает много, дорого и начинает диктовать свои условия. На конкурентном рынке глупо отказываться от денег в угоду методологиям. Хороший менеджер должен уметь сочетать любимую методологию разработчиков с необходимостью провести мозговой штурм, применить водопадную модель на ровном месте, при этом обеспечив скоординированность команды.
И вот тут менеджер должен уметь чётко формулировать, владеть средствами коммуникации и совместной работы, быть готовым забрать файл с сервера и разобраться в схеме проекта — для целей молниеносной, чёткой и однозначной коммуникации (а не бесплодных 5-часовых совещаний).
Учитесь мотивировать. Можно встретить тезис о том, что сильная и умная команда отлично самомотивируется и самоорганизуется. Нет, это не так. Всегда есть кто-то, кто а) мотивирует на постоянной основе и интересуется ходом работы; б) мотивирует по итогам работы и общается с руководством (не всегда понимающим и не всегда программистом); в) мотивирует в кризисной ситуации, сохраняя команду и устойчивость проекта.
Менеджер проекта — это мотор, который должен приводить в движение всю систему, обеспечивать согласованность всех элементов и максимально высокий КПД. Он не должен быть сторуким Шивой или двуликим Янусом, не должен быть образованцем, — он должен быть грамотным человеком, знающим, кто, когда, в какие сроки и за какие деньги решит часть проблемы. Если менеджер хочет выучить UNIX или научиться программированию — это похвально и поможет работе, поможет осознанию технических нюансов. Но это не должно делать из менеджера человека-оркестр. Такое положение дел только рассеет профессионализм, поскольку разбираться лучше в одном, но круто, чем во всём на троечку. Среднее арифметическое всё равно будет троечкой. В общем, дорогие менеджеры, не будьте той дурной головой, которая ногам покоя не даёт — думайте головой и всё закрутится как надо.
Наш сайт с абсолютно десктопным ПО для бизнеса и нашей флагманской RegionSoft CRM.
Наш Телеграм-канал BizBreeze. Всякое про CRM и бизнес, по уму, без копипаста и на 90% без рекламы. Подписывайтесь, там бывает прикольно. Комментарии (66)
atd
05.04.2018 13:43> Учитесь писать ТЗ и переводить с языка заказчика на язык задачи… техническое задание, которое можно будет согласовать, подписать и приступить к работе.
В этом вся разница между вашей и оригинальной статьёй. Её писали в Яндексе, а там нет такого, чтобы менеджер замыкал общение с «заказчиком» (внутренний заказчик — тоже заказчик) или пользователем на себя. А потом спускал кодерам готовое ТЗ (я начальник, ты дурак).
По моим ощущениям, разработчики (как минимум лиды) всегда принимают участие в выработке ТЗ, понимании потребностей, даже формулировке. То есть берут на себя какую-то частичку менеджерской задачи. Значит и менеджерам не зазорно немного окунуться в код, чтобы быть на одной волне со своей командой.
Axelus
05.04.2018 13:47+3Навык программирования по идее делает менеджера экспертом. Если этот менеджер занимается продвижением IT-технологий, то этот навык даст ему дополнительное более глубокое понимание продукта и его возможностей, и как следствие, уровень компетенции. Это неизменно должно привести к более эффективной работе. Лично мое мнение.
PMVyatkin
06.04.2018 14:16Есть ли уверенность, что человек 1-2 года занимавшийся разработкой на Дельфи, будет экспертом, начав управлять в компании использующей Java-стек?
Эффективность проектного менеджера в моем понимании — более быстрое и дешевое достижение проектных целей, в т.ч. в долгосрочной перспективе. Для этого надо коучить команду оценивать и кодить, а не оценивать и кодить самому.
AlePil
05.04.2018 14:31Менеджер может уметь программировать. И не только программировать — он может иметь какие угодно дополнительные скилсы. Главное, что бы дополнительные навыки не сказывались отрицательно на рабочих процессах внутри компании.
Уменее же думать оно вообще никому не помешает.
sshmakov
05.04.2018 14:48-2Учитесь писать ТЗ и переводить с языка заказчика на язык задачи.
В RegionSoft нет аналитиков?sshmakov
05.04.2018 16:55Вообще-то мне правда интересно. Из текста следует, что менеджер пишет ТЗ и передает его разработчикам. Навык полезный, конечно, не спорю. Но сколько ТЗ может написать один менеджер и где его аналитики?
Free_Mic_RS Автор
05.04.2018 17:17Почему же пишет и передаёт? С ТЗ может работать не один человек. Всё же интеграционные проекты — большая и сложная история, это вам не пару мест в браузере открыть. Всё пишем, всё успеваем, сроки не факапим, никто не жаловался. Остальные подробности раскрыть не могу :-)
sshmakov
05.04.2018 17:43Жаль, что не можете, вроде не самый страшный секрет.
Axelus
05.04.2018 20:46+3Я могу. В RegionSoft менеджеры никогда не писали ТЗ, поскольку это не их компетенция. ТЗ пишут постановщики задач, которые являются экспертами в области как бизнес-процессов, так и стека технологий. ТЗ пишется в процессе предпроектного обследования предприятия, которое планируется автоматизировать, либо после этого обследования. В этом процессе обычно принимают участие эксперты и представители группы разработки. При необходимости могут быть подключены и менеджеры, но исключительно для целей ориентации в потребностях заказчика. По факту готовности ТЗ и согласования его с заказчиком, оно передается в группу разработки, где над его реализацией работают программисты.
staticY
05.04.2018 14:49Я разработчик. Если я даю менеджеру обратную связь о блокировках в тасках, техническом долге, новых проблемах, предлагаю очевидные технические улучшения, в общем, делаю все, чтобы повысить эффективность, то я — хороший разработчик. Я проявляю обычную, очевидную инициативу и всем в итоге лучше. Менеджер может делать то же самое, только с другой стороны. Самый простой пример — отсутствие блокирующих тасков. Пример посложнее — уменьшить переключение контекстов разработчиками.
Умение программировать и понимание особенностей процесса изнутри — не может быть лишним. Это абсолютно очевидно. Нужно это конкретному менеджеру или нет — пусть сам решает.PMVyatkin
06.04.2018 10:16Я менеджер.
Я ставлю задачи разработчику, и они либо сделаны, либо нет.
Если они не сделаны, это плохо — первое, что я сделаю — я посмотрю, правильно ли я их поставил. Если нет — будут работать над постановкой, если да — узнаю у разработчика, почему мы сделали задачи плохо.
Сделать задачи плохо по моему мнению можно по трем причинам — недостаток планирования, недостаток исполнителя, внешние факторы. Первое я уже рассмотрел выше — мне остается понять, недостаток ли это исполнителя или внешние факторы. Если внешние — моя задача их убрать (например, разраба отвлекает другой ПМ — я поговорю с ним на предмет разделения времени, а так же обращусь к руководству с проблемой политики разбиения ресурсов на мелкие части).
Если это проблема исполнителя я буду искать причину — может он недостаточно квалифицирован (надо научить или перевести на другую работу, анализируя почему я дал ему задачу не соответствующую квалификации) или мотивирован (например разраб думает на работе вместо задач о том, что бы найти место пожирнее — моя задача понять мотивацию и подумать что он может сделать для компании, что бы мы платили ему много, а он приносил нам максимальную пользу).
Если наоборот, разработчик приходит ко мне с инициативами или решенными задачами, раньше сроков и в меньшие часы — для меня это сигнал, что я обладаю ценным ресурсом и моя задача аккуратно удержать его, следя за тем, что бы он не перегорел. А так же понять его мотивацию и передать ее другим участникам команды.
Зачем мне нужно умение программировать здесь? Что бы тыкать разраба что он не уложился в тайминг, вместо того что бы понять, почему мы пролошились с оценкой задачи, или почему сотрудника на другой проект выдергивает другой менеджер (не умеющий програмировать).
Потыкаю я его 2-3 раза, он свалит к конкурентом, посоветовав мне воспользоваться моим «умением программировать» что бы допилить проект самостоятельно.DrPass
06.04.2018 12:01Зачем мне нужно умение программировать здесь?
Вот, например, типовой кейс в моей жизни девять лет назад. Прихожу я работать этим самым менеджером в одну контору. Получаю тасклист отдела, директор просит по-возможности ускорить разработку отчетов, чтобы хотя бы через месяц их запустить в работу. Вижу отчет, который уже месяц делается. Расспрашиваю разработчика, почему так долго. Рассказывает про сложные выборки, про нестандартный дизайн, что структура отчета не ложится на схему данных CRM и т.д. Ту же байку, которую рассказывал предыдущему руководителю. Читаю техническое задание, открываю дизайнер отчетов, делаю его за пару часов. Ещё раз расспрашиваю разработчика, уже прижав к стенке. Выясняю, что он взял хорошую халтурку, и делает её в рабочее время, а этот проект отложил. Все равно же никто не проверит.
Поэтому случаи разные бывают (с) Все люди могут навешать лапши несведущему в какой-то теме человеку в своих интересах, и программисты тут не исключение.PMVyatkin
06.04.2018 14:24В моем понимании, менеджер хороший знает чем у него сотрудники на проектах занимаются.
Почему сотрудники как менеджеру вам не докладывали о текущих задачах, их статусах? Почему вам странным не показалось, что человек простые задачи делает долго, просирает сроки? Сколько осталось таких сотрудников в вашей организации, экспертизы которых у вас нет? Сисадмин полгода не разворачивает АД? Аналитик не пишет спеку 2 недели? Саппорт не закрывает инциденты годами? Вам для работе в такой команде нужна компетенция каждого, и за каждого придется сделать минимум одну задачу?
Теоретически, менеджеру надо 2 стендапа что бы понять, что сотрудник на работе занят не работой.
На практике есть 3 типа менеджеров — микроменеджеры, делающие отчеты, макроменеджеры — в заботах о стратегии компании на ближайшие 10000 лет и не знающие чем занимается конкретно сейчас их команда, и нормальные менеджеры, которые умеют управлять в среднесрочной и долгосрочной перспективе, но при работе с новой командой — начинают с анализа краткосрочных задач.
Я встречал компании, в ИТ которых руководили женщины сильно старше 50. И ИТ работала отлично, хотя женщины ни фига в ИТ не понимали — они понимали в управлении людьми, и держали руку на пульсе. Каждый день, анализируя скоуп задач отдела/команды и спрашивая со всех когда и какой результат будет, анализируя причины успехов и факапов.DrPass
06.04.2018 15:31В моем понимании, менеджер хороший знает чем у него сотрудники на проектах занимаются. Почему сотрудники как менеджеру вам не докладывали о текущих задачах, их статусах?
А как вам доклады без хотя бы общего знания сути выполняемых ими задач помогут адекватно оценить их корректность? Вот тот сотрудник добросовестно целый месяц докладывал предыдущему руководителю о работе, которую он проводит. Якобы. Тот, не будучи ИТ-специалистом, их читал и кивал головой, ок, разбирайся. Поэтому без соответствующей компетенции вы не в состоянии дать оценку, простая задача или не простая.
А сроки в ИТ — штука вообще сложно прогнозируемая. Вы почти всегда можете оценить общий объем работ, но вы не сможете оценить случайные проблемы с совместимостью каких-то компонент, или нюансы работы в окружении какого-то конкретного клиента и т.д., а всё это может всплыть в процессе работы совершенно произвольно. Всё, что вы можете — накинуть какой-то оверхед к посчитанной оценке на риски. И потом ещё доказывать вашему заказчику, что без него никак.
На практике есть 3 типа менеджеров
На практике есть разные составы команд и разные условия работы. У вас под рукой может быть профильный руководитель по какому-то направлению. А может не быть. И тогда будьте добры, проверяйте работу сами.
Вам для работе в такой команде нужна компетенция каждого
Именно поэтому у вас и зарплата выше. Я сейчас работаю директором небольшой ИТ-компании. И знаете, я не профессиональный маркетолог, бухгалтер, HR, финансист. Но у меня достаточно компетенций в каждой из областей, чтобы понимать, чем занимается мой маркетолог, мой бухгалтер, мой HR, и я могу понимать цифры в отчетности, да и при желании самостоятельно их посчитать. И да, даже самому себе быстро сделать отчёт. Это не даже близко не нужная мне компетенция с профессиональной точки зрения, но с её помощью я могу в разы быстрее получить нужные мне цифры, чем буду сначала объяснять начальнику отдела разработки, что мне нужно, а потом ждать результата. Это экономит время и деньги.
А самое главное выяснилось уже в процессе работы: не нужно быть семи пядей во лбу, чтобы знать на достаточном для эффективной коммуникации уровне всё вышеперечисленное, и многое другое. Поэтому я абсолютно серьезно говорю, что эти навыки не нужно противопоставлять. Они прекрасно сочетаются вместе.PMVyatkin
06.04.2018 17:02>> Тот, не будучи ИТ-специалистом, их читал и кивал головой, ок, разбирайся.
Вот я бы вот тут напрягся. У меня в команде много разных людей, и неадекваты тоже есть, и их видно. Когда вам человек замечания на документ простой не может написать 3 дня, вы о его стиле работы сделаете вывод сразу. Еще есть hr'ы которые свой хлеб у нас не зря едят и не берут кого попало, есть и функциональные руководители, кто смотрит загрузку постоянно и разбирается в предметной области лучше меня.
>> А сроки в ИТ — штука вообще сложно прогнозируемая.
В проектах типа MS Word — соглашусь ) В проектах типа обновляем ERP в компании на 2000 человек — не соглашусь, обычно все проблемы со сроками из за некомпетентности/желания сделать 33 проекта и получить бабла с 33 заказчиков одновременно.
>> Но у меня достаточно компетенций в каждой из областей
Вот именно, достаточно. Не надо 4 высших образования иметь, что бы понимать чем занимается бухгалтер или программист — если у вас есть схожий опыт работы, вы просечете это очень быстро. Если вы работали 5 лет аналитиком в ИТ компании, поверьте вы будете разрабов видеть насквозь. Хотя ни разу строчки кода не напишете.
>> не нужно быть семи пядей во лбу, чтобы знать на достаточном для эффективной коммуникации уровне всё вышеперечисленное, и многое другое
Вот и я про то же. Не надо уметь программировать самому — надо сесть и разобраться, загуглить, спросить экспертизу у коллег.
Я ПМом работаю и работал с многими компаниями и экспертизы часто в чем то не хватало — области заказчиков разные, один лекарства производит, другой мебелью торгует. Но садились и разбирались быстро, привлекали оперативно экспертов, и задачи клиентов решали — желание было.
staticY
06.04.2018 12:56Если наоборот, разработчик приходит ко мне с инициативами или решенными задачами, раньше сроков и в меньшие часы — для меня это сигнал, что я обладаю ценным ресурсом и моя задача аккуратно удержать его, следя за тем, что бы он не перегорел.
Если вы не умеете программировать — вам подсядут на уши карьеристы, и вы их не отличите от нормальных разработчиков. Во многих местах, в которых я работал — есть карьерист, который искусно присаживается на уши менеджерам. Такова жизнь.
мне остается понять, недостаток ли это исполнителя
Если вы не умеете программировать — как вы это поймете? Во многих местах, где я работал — есть врун-лентяй, который искусно спихивает ответственность от себя во все стороны, при этом держится на плаву с помощью выполнения простых тасков, дающих простой и объемный видимый результат. Этот врун на столько привык так себя вести, что почти никто (и даже он сам) не понимают, что он на самом деле врет. Понимают только специалисты, которые работают с ним бок о бок и периодически доделывают не свою работу.
В общем, тут можно бесконечно продолжать.
Я не говорю, что вам это нужно — выбор то за вами. Жизнь ваша и карьера — тоже ваша. Вполне себе можно быть руководителем подразделения, не зная специфики внутреннего устройства самого подразделения. У нас так пол страны устроено. Вопрос только в уровне профессионализма, который вы хотите достичь. Вот и все. Так что спорить не о чем.PMVyatkin
06.04.2018 14:29Менеджер обычно сам карьерист, чуть более успешно подсевший на уши топ-менеджерам ))) Или вы думаете менеджеры не думают о карьере, не умеют шантажировать руководство, не умеют выгодно показать результаты свой (часто, весьма не столь упорной) работы?
Во многих организация — плохие менеджеры. Менеджмент в России на уровне — я начальник, ты дурак. Но не везде, есть и нормальные управленцы, которые к команде относятся как к своему кошельку и знают, где в тот или иной момент какая монетка, и какого она достоинства. Опять же вопрос оплаты — за 50-80 тыщ вы ждете что менеджер будет решать такие проблемы? Да ему наплевать что там в организации происходит, он на пикабу сидит весь день, еще год не выгонят, а там новую работу найдет.
Про недостаток исполнителя все очень просто — если это не недостаток планирования, и не внешняя среда — это недостаток исполнителя. Никакой магии тут нет и быть не может.
staticY
06.04.2018 13:03Да, вот еще в догонку к первому комментатору: будучи разработчиком, я сразу же спалю, что человек занят на рабочем месте не тем, чем должен. Моментально спалю. Уверен, что разработчики даже не подумают в открытую врать менеджеру, зная, что он в прошлом — сам разработчик.
PMVyatkin
06.04.2018 14:31Тоже мне бином Ньютона! Думаете разработчик, который ниче не делает на работе, сидит и рандомные строчки кода набирает? Он сидит на пикабу, в викеюшке, телефоне, да где угодно. Да, если он на апворке работает парралельно, наверное не разработчик не отличит корпоративную среду разработки от некорпоративной.
Но нормальный менеджер это спалит в первый день, когда оцененные задачи на день не будут выполнены.
dart_w
05.04.2018 14:51Любой менеджер должен знать сферу в которой он работает. Соответственно, хороший руководитель в ИТ-сфере, должен знать (а лучше иметь профильное образование) в области ИТ (например, программирование, если он управляет разработкой) и, кроме этого, в каждом проекте погружаться в предметную область заказчика. Только так он может управлять специфичными рисками проекта. Если у менеджера нет такой экспертизы — он не сможет грамотно взвесить риски, о которых ему сообщает команда/заказчик и проект станет уязвимым. В итоге инициатива в управлении проектом перейдет либо к команде (отсюда все стоны вида «менеджер не понимает почему прямо сейчас нужен рефакторинг. Следующую версию мы уже собрать не сможем.») либо к заказчику («вы не учли то, то и то, хотя это было очевидно/мы это обсуждали см. ТЗ… Решайте эту задачу бесплатно в рамках багфиксинга»).
PMVyatkin
06.04.2018 14:35Вы какого то менджера описываете, не у которого нет навыков разработки, а который просто на проекте ничего не делает. Менеджер у вас что, не читал договор, не читал регламенты проведения рефакторинга, не читал регламенты выдачи релизов? Если нет — то гоните его, он на работе у вас видимо на другую контору работает.
По поводу рисков — поверьте, их взвесить грамотно не могут люди даже в своей области работающие. Пример — одну из самых известных компаний в Москве по консалтингу в сфере рисков закрыли за уклонение от налогов. Этот риск они не учли.DrPass
06.04.2018 15:39Менеджер у вас что, не читал договор, не читал регламенты проведения рефакторинга, не читал регламенты выдачи релизов?
Извините за нескромный вопрос, в скольких компаниях вы работали? В одной крупной и до безобразия бюрократизированной? В 99% компаний-разработчиков нет и никогда не будет ни регламентов проведения рефакторинга, ни многих других регламентов. Эти решения разработчики принимают самостоятельно.PMVyatkin
06.04.2018 17:13В 12 (4 государственные (внезапно одни из наименее бюрократизированных), 2 ~ 300 чел (одна очень бюрократизирована), 1 — 2000 чел, 2 — 100 чел, 3 < 20. 3 из них ИТ и только ИТ (и одна ИТ — та, что наиболее бюрократизирована). В маленьких компаниях — нормальных менеджеров (и нормального менеджмента) не видел. Видел хорошо доработанный и старательно примененный эджайл, который избавлял от необходимости в сильном менеджменте и регламентах.
Я скажу что хорошо делались проекты по fixprice в наиболее бюрократизированной компании. Хорошо — это в срок, в бюждет и без 19000500 обращений по гарантии, с клиентами которые возвращались.
bzq
05.04.2018 15:36Замечательно написано о том, что действительно делает из человека в менеджерской должности настоящим менеджером. Браво. Снимаю шляпку перед теми трудностями, которые пришлось пройти, чтобы всё это осознать.
Хотелось бы дополнить парой комментариев для подчинённых: если видите, что руководитель не успевает сделать что-то из вышеперечисленного, не стесняйтесь сделать это за него. Не надо сидеть ровно и тем более ныть, что меня, мол, недостаточно замотивировали, или ТЗ не совсем понятное, или ещё чего-там-ещё-кто-не-организовал. Это надо вам самим. Менеджерская работа по-хорошему дожна быть сделана, и не обязательно самим менеджером. Она вернётся сторицей в виде хорошо выполненного проекта или слаженностью команды. А систематическая помощь менеджеру со стороны подчинённого рано или поздно возвращается ростом зарплаты и/или карьерным ростом. Потому что сотрудник, который самоорганизуется в работе, куда как ценнее для работодателя, чем тот, с которым надо няньчиться.staticY
05.04.2018 19:12+1А систематическая помощь менеджеру со стороны подчинённого рано или поздно возвращается ростом зарплаты и/или карьерным ростом.
Мне кажется, вы — плохой менеджер, который ставит блокирующие таски, а впоследствии ищет виноватого. Карьерным ростом заканчивается стремление к карьерному росту (но это не точно). Ростом зарплаты заканчивается стремление больше зарабатывать (но это тоже не точно). Альтруизм — это альтруизм, и не больше.
Хотелось бы дополнить парой комментариев для подчинённых: если видите, что руководитель не успевает сделать что-то из вышеперечисленного, не стесняйтесь сделать это за него.
А потом намекнуть, чтобы заплатили, как начальнику? Или попросить отрефакторить кусочек кода? )bzq
06.04.2018 11:29+1Мне кажется, вы — плохой менеджер, который ставит блокирующие таски, а впоследствии ищет виноватого
Не вижу из чего Вы делаете такие далеко идущие и столь категоричные выводы, да ещё и в форме персонального обвинения. Как бы намекаю, что наезд был мимо тазика. И Вы явно путаете карьеру и карьеризм.
Дальше уже не лично Вам, так что «вы» будет уже обезличенным, и по правилам русского языка будет писаться с маленькой буквы. Поясню свою мысль, так как вижу, что нашёлся кто-то, кто коммент staticY выше плюсанул.
В специальности ИТ так же хорошо, как и в других сферах бизнеса, замечательно работает правило «спасение утопающих — дело рук самих утопающих». Если менеджер на вашем проекте — чудак на букву «м», то не стесняйтесь работать за него. Если за счёт этого вытянете проект, то в компании это должны оценить. Это шанс стать более полезным для компании, то есть для карьерного роста. Это хорошее основание поднять должность и/или зарплату. А если не оценят, то поменяете работу и с имеющимся опытом будете претендовать опять же на более высокую должность и зарплату.
А если менеджер адекватный, но просто не успевает или что-то упускает по каким-либо другим причинам (см. в статье развесистый список того, что делает хороший менеджер), то тоже будет только польза по тем же самым причинам. Это шанс для вашего карьерного роста. И я не зню ни одной причины не помогать менеджеру, если такая возможность представилась.
Выводы не бог весть какой глубины, но почему-то молодёжь к ним приходит очень долго, считая, что лишь углубленное изучение фреймворков (читай: технической части) открывает пути карьеры. А работодатель платит деньги не за знание фреймворков, а за решение конкретных задач бизнеса. И не каких-то там «тасков», а скорее проектов, если оставаться в ИТшной терминологии. Фреймворки же могут пригодиться решать поставленные задачи быстрее или лучше, а могут и не пригодиться…staticY
06.04.2018 14:16-1Если менеджер на вашем проекте — чудак на букву «м», то не стесняйтесь работать за него. Если за счёт этого вытянете проект, то в компании это должны оценить.
Это хорошее основание поднять должность и/или зарплату. А если не оценят, то поменяете работу и с имеющимся опытом будете претендовать опять же на более высокую должность и зарплату.
У нас разные подходы к карьерному росту. Я расту за счет роста своего профессионализма в своей технической сфере, потому что я не хочу становится директором по продажам (оставляю это место тем, кто больше ничего не умеет). Я предоставляю бизнесу хорошо продуманный человеческий интерфейс для воплощения бизнесовых хотелок в виде программного кода/архитектуры. Какие делать хотелки и за какие сроки и прочее планирование — это не моя юрисдикция, в моей юрисдикции навалом другого более сложного планирования.
Да, я иногда залажу в смежную область управления. Просто потому что не хочу превратиться в аутиста, который замкнут и оторван от мира. Я в курсе, как у ребят сверху обстоят дела и знаю, как они продают продукт, который я пишу. Знаю, что про продукт говорят клиенты. Но я не делаю не свою работу. Потому что не вижу в этом никакого смысла, ибо у меня свой бизнес — «Написание программного обеспечения как услуга», в котором есть своя карьерная лестница, которая не основывается на понятиях «не стесняйтесь работать за него и тебя, возможно, повысят». Для меня подобный подход — бред.bzq
06.04.2018 14:27+1У нас разные подходы к карьерному росту.
Значит мой совет был не для Вас, и его можно было просто проигнорировать.
Для меня подобный подход — бред.
Искренне рад, что Вы нашли полностью устраивающий Вас путь своего развития. Держите нас в курсе (:
PMVyatkin
06.04.2018 14:37ИМХО помощь предложить стоит. Но сделать за него — клиника. Что будет если отчет о статусе проекта заказчику разработчик пришлет? )
CoreTeamTech
05.04.2018 15:42К сожалению, вывести специальный обобщенный вид менеджеров не получится. После всех подобных статей всегда остается образ «адекватного руководителя» во всей широте смыслов слова «адекватный». Иметь навыки исполнителя или не иметь — это вопрос не философский, тем более не холиварный. Если есть возможность иметь дополнительные навыки, то лучше их все же иметь, чем не иметь (простите за тавтологию). Главный скилл менеджера — это работа с командой, с людьми то бишь. Его задача в эффективной утилизации ресурсов и компетенций.
Менеджер — не аналитик (зона отвественности — предметная область и требования).
Менеджер — не техлид (зона ответственности — используемые технологии и практики).
Менеджер — не тимлид (зона ответственности — оперативный контроль задач команды).
Менеджер — не программист (зона ответственности — разработка).
Менеджер — не QA специалист (зона ответственности — качество).
Менеджер — не технический писатель (зона ответственности — документация).
Менеджер — не продавец (зона ответственности — продажи компетенций, услуг или продуктов).
Менеджер — не маркетолог (зона ответственности — анализ рынка, планирование и продвижение услуги/продукта).
Менеджер — не HR (зона ответственности — карьера сотрудников в компании).
Может ли один человек иметь все вышеуказанные компетенции, да еще и на высоком уровне? Наверное может. Однако, это большая редкость. И в данном случае, у такого менеджера должно быть своеобразное расслоение «личности». При решении каждой задачи надо понимать, какую из этих компетенций он задействует. И если такая компетенция уже есть у кого-то в команде, то лучше задачу делегировать. В противном случае, если на это уходит достаточно много времени и регулярно, то необходимо добавить эту компетенцию в команду, путем найма нового сотрудника, четко описав требования к вакансии.
Но есть нюанс. Менеджер должен предоставлять хороший интерфейс ко всем этим комппетенциям. А значит иметь достаточное представление о них. Если вы разработчик и желаете понять как вам вырасти внутри компании, то менеджер должен предоставить вам канал к HR или менеджерам других команд. Если маркетолог придумал супер-продукт, то менеджер должен предоставить канал к компетентным техническим специалистам, чтобы те могли дать объективную оценку. Если тетка из бухгалтерии заказчика не идет на контакт с аналитиком, то менеджеру необходимо наладить из взаимодействие. И так далее и тому подобное.WMasterTS
05.04.2018 19:16+1Вот, да. Менеджер очень перегруженное слово и тыкается везде где придется. Из моей практики видно следующее, на ранних стадиях «менеджмент» это дополнительный навык к основному, те программист с навыками менеджмента может быть техлидом или тимлидом так как дополнительно к организации технической архитектуры он может еще организовать ресурсы под нее, что собственно очень логично. Перевес случается когда дело доходит до так называемого General Manager, те Менеджер который организует других менеджеров, вот там чистый менеджмент как основной навык и проявляется. Еще есть куча литературы которая обсуждает эти грабли, The Pragmatic programmer, Software Architecture in Practice, тот же SWEBOK неплохо проходится по этому поводу и все это крутится вокруг понимания процесса SDLC в принципе
PMVyatkin
06.04.2018 14:39А программист не перегруженное слово? ) ИМХО так же как менеджер используется. Только в случае с разработчиком — все вникают в ньюансы, на чем кодишь, бэкэнд, фронтэнд, ДБ или что то еще.
С менеджером — тыжменеджер, значит дожен уметь все (и вот теперь кодить, внезапно тоже!).WMasterTS
06.04.2018 16:45Да то же самое конечно, поэтому я думаю важно не забывать приставку. Из топика не сильно понятно но я думаю речь идет о так называемом project manager если да то это административная роль фокус которой направлен на администрирование сроков, затрат, качества выпускаемого продукта, вот тут www.apm.org.uk/resources/what-is-project-management все написано. В чистой роли project manager может не знать ничего о программировании и это будет ок потому как его специализация это администрирования проекта. При этом у него даже может не быть подчиненных итп так как он администрирует проект а не людей. Как то так
PMVyatkin
06.04.2018 17:14Про ПМа и подчиненных — 100% согласен. У него подчиненных нет, есть стейкхолдеры.
Raftko
05.04.2018 16:26Как мне кажется, тут не про менеджера, а про специалиста в общем. Обладание смежными навыками временами даёт хорошую выгоду. Когда ты понимаешь как устроенно всё у коллег тебе проще с ними взаимодействовать. Например, если вы работаете в веб студии, которая не только разрабатывает, но и продвигает сайты, знания базового сео ещё и на этапе создания и продумывания решений могут позволить избежать ошибок и по итогу меньше претензий будет у сеошника и меньше придётся переделывать. Также и в разработке ПО, бекграунд менеджера может помочь вам подсказать менеджеру какие-то не очевидные риски. Да эти навыки, вторичны, но помогут выделиться из общей массы в лучшую сторону.
odissey_nemo
05.04.2018 23:49+1Менеджер, по моему существенному опыту в крупных, и средних но богатых, конторах- это лишь приказчик, следящий за исполнением планов и подгоняющий реальных исполнителей. План обычно верстается заказчиком, аналитиком исполнителя и бухгалтерами с обеих сторон. Получение заказа обычно обеспечивает «продавец», «босс», «кто-то ещё», умеющий ходить в баню, проверенный на откаты и вхожий в места «необщего пользования».
В таком окружении менеджеру лучше не тратить времени на специальность (в среднем. в общем), а сразу тренироваться в способности чуять и удовлетворять нужды начальства любыми средствами. Да и платят менеджерам побольше. Но работа нервная, всё зависит не от тебя.
Помню, увольнялся в 2016 году, и разговорился тогда с нашим молодым руководителем департамента, практически менеджером. Его прямые слова: — да, я и сам был и работал программистом. А потом смотрю, манагерам то больше платят. Так что-же, думаю, я тут делаю? И переквалифицировался в менеджеры.
Человек он был неплохой в целом, но принимал жёсткие решения по отношению людей, в два раза его старше, легко. Мог опоздать на совещание на час, а потом позвонить ожидающим его в зале сотрудникам и сказать: — а я тут кофе пью и скоро приду.
Хотя воспитывался у нормальных советских людей, знаю точно, не из-за бугра его прислали.
Предыдущего в той же конторе прислали из-за бугра. Был активным, вежливым, шустрым, не опаздывал, и говорил с акцентом, после длительного пребывания в США. В целом с ним было даже легче, проще, определённее. даже живее, хотя и от личности зависит. Ведь менеджер — это чисто американская должность в американского типа экономике. которая тырит реальные ресурсы со всего мира за свои виртуальные деньги и позволяет себе больше трат на обеспечение своего внутреннего спокойствия.
Всё — ПМСМ!
stepuncius
06.04.2018 09:56К названию статьи вспоминается:
«I think everybody in this country should learn how to program a computer because it teaches you how to think»
(“Думаю каждый в этой стране должен учиться программированию, потому что это учит людей думать”).
Стив Джобс
k0nst
06.04.2018 09:56-1Сколько менеджеров выпускается ежегодно из ВУЗов России и ближнего зарубежья? Тысячи, если не десятки. Кто из них может реально сформулировать в чем его задача, как выпущенного специалиста? Почти никто. Но они не виноваты, потому понятине менеджера у нас «расплылось» и дискредитировалось.
Чтобы оценить масштаб вакханалии можно просто взглянуть на нейминг позиций некоторых банков и организаций. Самая начальная или, вообще, низшая позиция обычного работника нередко называется «менеджер по чему-то там». В одном из банков вовсе у разработчиков и админов позиции назывались примерно, как «менеджер по разработке чего-то там» и «менеджер по обеспечению чего-то там». Смысл в том, что номинально менеджер — это управленец. Номинально управленцу уметь программировать не нужно, ведь с этим не нужно спорить? Но здесь в дело вступает контекст нашего рынка труда и как он формировался. Так уж получилось, что наш рынок труда не узкоспециализированный.
Хочешь не хочешь, а в любой сфере приходится ни то, что заниматься, но точно хотя бы вникать в темы не своей зоны ответственности. Конкретно в случае с менеджерами, если это не супер топ-менеджер гос. уровня, то скорее всего он, как и все подобные, находится в условиях конкуренции. И именно в рамках этой конкуренции и рождаются такие «сайд скиллы», как программирование у менеджеров.
Это не только менеджеров касается. У меня есть друг, который с самого выпуска работает в сфере продаж. Он настоящий продажник и уже имеет много лет опыта, но тем не менее, он изучает психолгию и даже психиатрию, поведенческие модели, в общем читает много подобной литературы. Уж не знаю, на сколько это полезно в его сфере, но судя по тому, что он весьма успешен, то думаю — да.
Несомненно, программирование, как сайд-скилл — это плюс для менеджера, особенно если он работает в IT сфере. Но, честно говоря, в статье я увидел серьезные пересечения зон отвественности. Например, на уровне кода проект должен знать максимум тим-лид, а уж менеджер проекта, которого я вижу product-owner'ом в данном контексте, подобного знать не должен. Он должен знать как его продукт решает user-кейсы и stories, которые спустились от аналитиков, что тоже мелькает в статье в зоне отвественности менеджера. В общем материал хороший, но очень субъективный :)
PMVyatkin
06.04.2018 10:04+1За всех менеджеров не скажу, скажу за менеджеров проектов.
В PMI PMBOK (6) роль менеджера проекта сравнивается с ролью дирижера оркестра — он хорошо разбирается в музыке, умеет играть на каких-то инструментах, обладает определенным опытом в музыке и организации.
Но вот вопрос — вы выдели хотя бы на одном концерте, что бы дирижер оставил пост, бросил палочку и сел за инструмент? )))
Даже если кто то играет не в ноты, дирижер не сядет на его место. Хороший дирижер строит оркестр и не допускает, что бы на концертах такое случалось — делает много репетиций, ищет людей, развивает их, не дает им срулить за день до концерта и т.д.
Представляете ли вы что главный конструктор летательных аппаратов тратит свое время на то, что занимается сваркой или заклепкой швов? Представляете ли вы себе, что бы главных архитектор крупного здания (например, ГЗ МГУ) сам приехал класть кирпичи и делать лепнину (всего лишь лет 500 на это бы у него ушло)?
То же и с ПМом — как бы вы хорошо не кодили, идите делать это в свободное время, на OpenSource или на upwork.
ПМ должен заниматься пмством, если, например, команда плохо делает оценки — он должен обозначить это риском, подумать о развитии команды, подключить людей с экспертизой. Если он ставит оценки сам — он очень плохой ПМ — он не может эффективно наладить работу на проекте, найди общий язык с командой и руководством, объяснить какие ресурсы нужны для проекта и защитить свое мнение.DrPass
06.04.2018 12:06Но вот вопрос — вы выдели хотя бы на одном концерте, что бы дирижер оставил пост, бросил палочку и сел за инструмент?
А вы видели хотя бы одного дирижера, который не умеет читать ноты и не знает партитуры инструментов? Да и играть дирижеры тоже умеют на чём-либо, все они так или иначе когда-то были музыкантами.
Точно так же главный конструктор летательных аппаратов знает технологии сварки швов и заклепок, знает, когда и в каких условиях их применять, как технические, так и экономические аспекты технологий. И когда-то он крутил гайки.
Речь тут идет про «понимать, что делают программисты», а не про «программировать в команде».PMVyatkin
06.04.2018 14:47А вы видели хоть одного менеджера, который не умеет читать на языке, котором ведет проект? Или писать на нем? Или вы думаете задачи в трекере и ответы о тестировании и внедрении пишутся на языках программирования? Или, для того что бы менеджеру организовать отчетность о тестировании или разработке на проекте — нужно программирование знать?
Да и ИТ редко попадают из строительства или филологии, так или иначе опыт работы в ИТ у всех менеджеров в ИТ обычно есть (скорее всего аналитика, но может быть и сисадминство, техподдержка, продажи). Совсем уж левых людей тут нет — дворника или поэта ПМом работать внезапно не возьмут.
Для того что бы понимать что делают программисты — программировать не надо.
Для того что бы быть уверенным, что у тебя нормально сварен шов — надо посмотреть отчет о тестировании сварки, и если он провален — заставить команду сварки (через ее руководителя) сделать так, что бы он был ок. Как заставить — методов материальной и нематериальной мотивации у менеджера полно — например, уверенно объяснить что после еще одного проваленного шовного теста будет увольнение и уголовное преследование.
А сидеть и учиться швы варить — и тем более учить этому сварщиков — неправильно. Это значит, что менеджер у себя ситуацию не контролирует вообще, если он до такого доходит, и проектом управлять не способен.
africaunite
06.04.2018 11:18Ну, Вы привели отличные примеры.
Оркестром не будет управлять прораб, ракеты не строят главные хирурги, дирижер не уследит за торговым центром.
Edit: это был ответ на предыдущий коммент, прошу прощения. Менеджеру хабрахбара: на последний комментарий первого уровня всегда очень трудно создать ответ.
PMVyatkin
06.04.2018 14:53Хирург не может строить ракеты, но он может стать главным врачем в клинике. В клинике, где будут хирурги, терапевты, стоматологи, патологоанатомы, водители, уборщицы, строители и даже менеджеры по продажам, а даже IT.
И хирург этого всего не должен уметь. А точнее — дожен знать все по верхам и уметь подключать экспертизы.
Если тебе начитотдела ИТ говорит что делать сайт клиники — 10 млн, ты даешь заму задачу сделать RFP, позвонить в консалтинг, собрать 5 КП и 5 оценок RFP и выдать 5 КП. После чего либо начальник ИТ отдела идет на мороз за некомпетентность, либо тебе специально обученный менеджер по продажам в КП объясняет ПОНЯТНО почему это столько стоит — и это поверьте мне более чем реально сделать, переведя конкретные трудозатраты на язык бизнеса.
exebit
06.04.2018 16:52Менеджер должен быть адекватным. Будь он экспертом или профаном в предметной области, он должен понимать предел своих компетенций и обращаться к настоящим экспертам при необходимости.
tihomirovaaleksej
07.04.2018 12:44Согласен, что полным профаном в программировании менеджер быть просто не имеет права быть, но вместе с тем ему просто незачем иметь идеальные скиллы в этом, ибо тогда нет необходимости в программисте. А вот вопросы взаимопонимания стоит, наверное, рассматривать больше с точки зрения человеческих качеств и командной работы.
DrPass
Честно говоря, я не понимаю, почему многие противопоставляют скилл программирования у менеджера другим скиллам. Т.е. если он вдруг умеет программировать, то он перестанет уметь думать, управлять, понимать особенности продукта, общаться с заказчиком, <впишите ещё какой-то более важный скилл для менеджера>?
Конечно же, навык программирования у менеджера в ИТ вторичен. Но если он есть, то он действительно в ряде кейсов повышает эффективность менеджера, поэтому воспринимать его в штыки не нужно.
jetcar
можно примеры где программирование полезно менеджеру
vermeleon
Например в разговоре с заказчиком
jetcar
нее там программирование не нужно, чтоб отбривать тупые и слишком сложные для данного бюджета идеи нужен архитектор/лид который скажет сколько будет стоить ещё одна кнопочка которая делает всё хорошо, менеджер об этом не знает, а потому может пообещать сделать то что ему кажется просто ведь он же умеет «программировать»
DrPass
Именно там и оно и пригодится. Менеджер в идеале сам должен адекватно оценивать объем и стоимость работ, а не доверять в этом архитектору/лиду. Обсуждение условий с заказчиком, это его непосредственная ответственность и квалификация, а не техлида. Тем более что интересы техлида нередко противоположны интересам заказчика, а точка сделки будет где-то посередине. И хороший менеджер знает, где заказчик пытается занизить цену, а где техлид завышает оценку, и заставляет обоих идти на компромисс. Но чтобы это сделать, ему действительно нужно понимать хотя бы в общих чертах, что и как будет делаться в рамках данного технического задания.
jetcar
всё конечно зависит от сложности продукта, там где раз, раз и в продакшен и самый опытный девелопер это всё таки ещё джуниор тогда знание программирования на просто необходимо чтоб ускорить процесс, накидал быстренько ТЗ и отдал делать, программист уже по шаблону залепит всё что надо и можно в продакшен пихать, а там где программисты делают более сложные штуки желание менеджера оценить задачу исходя из своих знаний приводит всегда к проблемам, для менеджера важнее выяснить важность поставленной задачи от клиента, чтоб он мог так сказать совершить сделку между технической частью и бизнесом, а не потакать клиенту с любыми просьбами лишь бы тот денег дал, а там программисты как-нибудь справятся, хаков налепят если нужно, проект то большой одним хаком больше одним меньше, ещё и на суппорте можно заработать…
DrPass
Вы правы. Но сделка — это почти всегда компромисс. Её не нужно перегибать ни в сторону заказчика, ни в сторону программистов. Заказчику свойственно необоснованно занижать сроки и стоимость, тимлидам/архитекторам — наоборот, завышать, причём тоже зачастую без веских оснований. Про программистов я обобщений делать не буду, тут бывает зоопарк мнений, от «да я сегодня сделаю» (для задачи, которую по факту он будет неделю в запарке решать) до «ну, недели две» (для задачи, которую он сделает за полдня).
AlexTOPMAN
Т.е. нужно таскать с собой на встречу с клиентом ещё и «кузнеца» тимлида? Или встречаться итерационно: М+З, М+ТЛ, М+З, М+ТЛ… пока не придёт взаимопонимание?
PMVyatkin
Поверьте, если вы как менеджер, будете в переговорах использовать программирование, вместо переговорных навыков и навыков управления заказчиком, пролетите вы очень быстро.
Пример — у нас был подрядчик, с менеджером, который очень хорошо разбирался в предметной области (не разраб, а скорее консультант).
Он круто объяснил нашей команде на встрече что к чему, мы не все поняли, и не стали окать решение. Вместо того что бы додавить нас, и направить нам письменно решение о выборе функционала со сроками ответа, он положился на наше «Ну казалось бы мы ок».
Когда пришле время вставлять решение в документацию — мы написали что мы не ок, и просим дополнить документ 100500 схем, таблиц и описаний.
Менеджер в шоке позвонил — мы же договаривались до другого? Мы сказали что не договаривались ни до чего, наше «казалось бы ок», не значит что мы подписываемся под чем то. По договору вы должны документ с нашими хотелками — это наша хотелка. То, что вы не запросили и не задокументировали решение (хотя бы в почте, не говоря уж про протокол встречи и его согласование) — проблема вас, как менеджера, за вас это никто не сделает.
А был бы вместо него нормальный менеджер, который бы просто прислал протокол в почте — с запросом на согласование или обозначением, что если замечаний в течении 2 рабочих дней нет, протокол считается согласованным, переговорная позиция подрядчика была бы совсем другая )))
DrPass
Речь шла не про «вместо», а «вместе с»
PMVyatkin
Не уверен, что эти инструменты нельзя противопоставить.
Когда ты на переговорах показываешь экспертизу — это не всегда сыграет в твою пользу, ибо ты сказал «Ага, я немного разбираюсь в БД, эти работы должны стоить дороже», а тут вышел датабэйс-девелопер (которого неделю назад переманили из яндекса) и твою точку зрения разложил и обосновал меньшую цену.
Если бы ПМ не сказал «Я разбираюсь» — можно было бы просто взять таймаут. Тут же заказчик будет давить «Вы же сказали что у вас есть экспертиза и потратили наше время на ваши объяснения, а когда мы привели аргументы вы теперь берете таймаут? Это стиль работы вашей компании?».
Навык лишний конечно не помешает. Но это не значит что надо в переговорах с пациентами этими навыками аппелировать, особенно когда ты не полностью в теме. Занимайтесь своим делом, и тем, что вы знаете профессионально. Разраб не лезет в менеджмент проектов, водитель такси не лезет в политику, патологоанатом не лезет лечить людей, и т.д.
Busla
В оригинальной статье смешивается навык программирования и опыт работы программистом.
Навык программирования — это макросы и прочая автоматизация рутинных задач, то чем должен обладать продвинутый/опытный пользователь, что позволяет эффективно пользоваться компьютером. Менеджер — совершенно не исключение. Этим навыкам довольно быстро овладевают даже представители явно творческих профессий, потому что избавляют их от бездумного кнопконажимательсва.
А опыт «промышленной» разработки ему не требуется — это явно не этап профессионального развития управленца.
Predictions
Вероятно, ответ кроется в этом. Вопрос в том, как менеджер использует этот навык. Если начинает не доверять технической команде и начинает проверять их архитектурные решения чтобы точно убедиться что они верно понимают задачу, тогда это, вероятно, вредит процессу больше, чем приносит пользу, потому что это растрата ресурсов, и вероятное негодование со стороны команды. Еще хуже, когда менеджер начинает продавливать (именно продавливать, не предлагать) свои технические решения.
Как вы видите повышение эффективности менеджера если он знает программирование?
У него всегда под рукой должен быть тех. лид команды или архитектор для больших или важных встреч, поэтому ему эти навыки в целом почти не нужны, для этого есть другие люди из его команды.
Lofer
Менеджеру это скорее полезный навык, позволяющий повысить положительные риски и понизить отрицательные. Команда и технологии — это инструмент менеджера и он обязан их хотя бы понимать.
К примеру — корректно проектными метриками оперировать. Корректно понимать жизненный цикл решения. Корректно организовать работу с проектной документацией.
Корректно посчитать бюджет проекта.
Корректно объяснить Клиенту «почему именно так» и «что будет если ...».
Когда приходит менеджер проекта и говорит — я уже пообещал что «мы ЭТО сделаем к....» — это просто ()o().
Хотя бы что бы понимать, куда ему самому не стоит лазить без команды. Если менеджер проекта сможет просмотреть проектную документацию и найдет там проблемы, хотя бы на уровне не покрытого или противоречивого требования — вообще будет хорошо.
PMVyatkin
Управлять рисками можно с помощью управления рисков.
Если менеджер не способен из каждого участника команды выжать возможные риски и правильно их оценить, значит он должен разбираться во ВСЕЙ области проекта.
Внедряешь 1С — знай весь бухучет, федеральные законы по учету, законы по выплате ЗП, правила аудита, программирование, системное администрирование (WinSrv, unix; PosgreSQL, MS SQL), базы данных, сети. Не хилый такой ПМ получается.
Если ХОРОШИЙ ПМ обещал что то заказчику — значит этот CR он обработал заранее, согласно процедуре управления изменениями, в которой должны быть прописаны люди, которых решение затрагивает и от них было получено согласие, после чего обещание было озвучено заказчику.
Если менеджер считает что процедуру управления изменениями придумали бюрократы из PMI, а заказчику можно обещать вот так, на свое усмотрение — видимо, у вас плохой, негодный менеджер — аналог такого менеджера, это разраб, который код в релиз самовольно дописал и никому не сказал, а потом пришел и сказал — «я уже включил это в релиз, да ни тестирование, ни релиз-менеджер, ни ПМ, ни заказчик, ни аналитика не в курсе».
Lofer
Управлять рисками
можнонужно с помощью управления рисков.Полагаю, что с этого нужно начинать :)
А все прочее — просто инструмент для управления рисками (хотя бы на этапах идентификации и анализа).
PMVyatkin
Про нужно — согласен )
Но, ограниченная экспертиза ПМа в области какой то — плохой способ управления. ПМ который 22 проекта сделал похожих, оценит риски намного лучше, чем ПМ без проектов с подобным скоупом, стейкхолдерами и ограничениями, но со знанием разработки )))
AlexTOPMAN
Противопоставлять скиллы, это всё равно как спорить: жене нужно лучше готовить или лучше воспитывать детей. Философски (т.е. вообще) — это глупый и ненужный спор. Предметный же, к конкретной ситуации и по конкретному человеку, то — чего ему не хватает, то и нужно подтягивать. Остальное — пусть будет. Рано или поздно понадобится.