Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Как подружить разработчика и менеджера

Все компании, а тем более проекты, разные: отличаются задачи, подходы и команды. Их объединяет лишь одно — напряженность между менеджерами и разработчиками. В предыдущей статье я писал о том, что значит быть лидом (а это во многом значит быть менеджером). Наверное, такой опыт позволяет иначе взглянуть на ситуацию и попробовать копнуть тему глубже, чем «технари против гуманитариев» или «исполнитель против руководителя». А разобравшись, подумать, стоит оно того или нет.

В любой статье на DOU о менеджерах легко найдется хотя бы один из следующих комментариев:

  • «Scrum не нужен, ведь деды пятилетками нейросети на перфокартах писали».
  • «Менеджеры — дармоеды. Только требования дайте, а дальше мы сами».
  • «Митинги — зло. Договаривайтесь без меня, но чтоб по-моему решили».
  • «Софт-скилы для софт-людей. Лучше про код думайте».
  • «JavaScript не язык, Front-End не программист».

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

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

Иллюстрации Каталины Маевской

Война миров

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

В то же время менеджер работает с людьми, которые меняют мнения, врут, ошибаются, несут чушь и верят в гомеопатию. При этом менеджер должен все это выслушать, собрать воедино, отсеять ерунду и придумать, как на этом деньги заработать. Таким образом, в мире людей ничего не определено, а можно опираться лишь на какие-то данные, пару мнений и свое чутье. Вроде бы все круто, но завтра конкурент зарелизил новую фичу — и ты в пролете. А программисты говорят тебе, что «антиэкранирование происходит из-за того, что переносчики сильного взаимодействия, которому подвержены глюоны, сами обладают цветовым зарядом и в процессе движения как бы „порождают новые глюоны из вакуума“, усиливая тем самым взаимодействие» (примерно так для менеджеров звучат рассуждения программистов о невозможности сдвинуть кнопку на 2 пикселя влево).

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

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

— Друг, нужна таблица с котятами!
— Не вопрос. А сколько планируется котят в системе?
— Ну 5–10... А может, и 1000.
— Хм, 1000 котят... Надо прикрутить пагинацию, сделать ленивую подгрузку, проверить на разных девайсах и скоростях... Нужен месяц.

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

Во-первых, огромный разброс по исходным данным в требованиях. Так пара десятков котят или пара тысяч? Откуда эти цифры? Поскольку менеджер живет в вероятностном мире, он видит возможность того, что котят будет именно 1000. Даже если такой человек будет один, а у остального миллиона пользователей будет от 5 до 10 котят. Почему бы не сделать продукт хорошим для всех?

А что услышал программист? Он услышал о лимите в 1000. Но ведь когда он будет писать код, то не сможет только чуть-чуть поддерживать определенный кейс. Его надо будет либо поддерживать, либо нет. Соответственно, он проектирует решение под 1000 котят, хотя в 99% случаев их будет на несколько порядков меньше. Отсюда и месяц.

При этом стоит лишь немного поменять диалог, и эта проблема исчезнет сама собой:
— Нужны котята в таблице!
— О’кей, сколько их?
— От 5 до 10. А если 1000, то насколько дольше будет?
— Ну для 5–10 я сделаю за 3 дня, а для 1000 — за месяц.
— Много котов в одной таблице к беде. Делай для 5–10, а там посмотрим.

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

Приведенный пример демонстрирует очевидную вещь: в большинстве проблем виновата коммуникация. О ней далее.

Мисс коммуникация

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

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

Детали имплементации

Разработчики, внимание: далее следует жестокая правда! Менеджерам абсолютно, тотально, невероятно и глубоко фиолетово плевать на то, как вы реализуете фичу в техническом плане. Их интересует другое: насколько быстро, качественно и надежно вы ее сделаете. И эта осознанная невежественность — не капризы или лень, а необходимость. Это ваша работа, а им зачем влезать в нее? У них своей хватает. Ведь вы и сами беситесь, когда к вам лезут с советами.

Это редко выступает большой проблемой, но она отнимает много времени, особенно на митингах, а иногда становится причиной просто-таки детских обид разработчиков (что их не слушают, а значит, не уважают). Поэтому вы, программисты, оставьте технологии программистам, ибо они неинтересны менеджерам. А вы, менеджеры, если хотите быть не погонщиками, а любимыми господами/госпожами, дайте иногда кодерам высказаться. Сделайте умные глаза, задайте пару уточняющих вопросов и скажите в конце: «Круто!» Вам же с ними потом работать.

Синкапы

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

Отсюда эти вечные вопросы:

— «На каком ты этапе?»
— «Успеваешь уложиться в эстимейт?»
— «Получится залить сегодня на стейдж?»

Чаще всего эти вопросы задаются не с целью давления, как кажется разработчикам, просто менеджеры искренне не знают! Помню, как меня напрягало, когда в течение дня мне писала ПМ: «Привет! Как дела? Успеваешь доделать?» Сейчас я ее понимаю: есть обязательства и встречи с клиентами, на которых она должна либо показать, что обещали, либо объяснить, почему не успели. Это ее работа. Но для меня это выглядело как постоянный прессинг, особенно когда понимаешь, что с эстимейтом промахнулся.

Как минимизировать этот стресс, будучи разработчиком? Во-первых, перестать воспринимать эти вопросы как сомнения в своих навыках и просто отвечать как есть. А если видишь, что что-то идет не по плану, вообще написать первым. И менеджеру поможешь, и сам от лишних вопросов избавишься. Вот честно, лучше сразу написать: «Сегодня не отдам», чем сильно спешить, сделать плохо и отдать то, что крешнется на демо. А менеджерам нужно поменьше спрашивать, вот и все. Микроменеджмент до добра не доводит.

Назад в будущее

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

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

Так возникают ситуации, в которых каждый пытается перетянуть другого в свою временную линию:

  • тестировщики дергают программистов в прошлое («Можешь глянуть? Я тут кликаю задачу, которую ты неделю назад двинул в QA, и...»);
  • программисты тянут менеджеров в настоящее («Я тут читаю acceptance-критерии, и это какая-то дичь. Почему...»);
  • а менеджеры тянут программистов в будущее («Нужно, чтобы ты взглянул на эту фичу и примерно оценил. И что значит дичь?!»).

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

«Эй, ты не занят?»

Столько на эту тему сказано, а никто, похоже, не слушает. Представьте, что вы пытаетесь уснуть, и в тот момент, когда вы почти отошли в мир, где доллар по 100, а сыры по 10, вас трясут за плечо и спрашивают: «Извини, ты уже спишь?». И так раз 10 за ночь, причем еженощно. Разработчикам это ощущение знакомо: то же самое они чувствуют, когда входят в состояние потока, а их выдергивают фразой: «Ты сейчас занят?»

Честно, я не фанат всех этих сладких теорий о том, что программист — это краснокнижное животное, вокруг которого надо водить хороводы и петь йодлем. Но есть у него одна особенность: для продуктивной и качественной работы ему нужно время. Правильное время — непрерывное, как минимум 3 часа, на протяжении которых он сможет сосредоточиться на одной конкретной задаче. Обед, синкап, а иногда даже обычный вопрос о погоде ставят точку на текущем временном интервале, и его нужно отсчитывать заново. А тут есть проблемка.

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

Решить это достаточно просто в 2020 году — с помощью мессенджеров. Менеджеры, тестировщики, а особенно другие разработчики, не дергайте человека вживую, даже если он сидит на соседнем стуле! Договоритесь об удобном всем канале связи и пишите туда. Будет время, он глянет и ответит. Нет — значит, ждите либо дергайте, но будьте готовы привести веские доводы в пользу такого решения.

Cloud microservice blockchain multi-tenant AI solution

Почти каждый менеджер, которого я знаю, в своей речи к месту и не к месту вставляет различные баззворды. Мне кажется, их на это вдохновляют разработчики. А менеджеры думают, что так с последними будет проще найти общий язык. Ну и звучит круто. Однако есть нюанс: надо все же понимать, что ты вообще несешь! :)

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

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

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

Не самым плохим вариантом будет, если технический специалист, услышав термин от менеджера, просто уточнит, правильно ли он его понял. Но ведь не каждый раз так делать? Даже в моей практике бывало много ситуаций, когда мы с менеджером поговорили, вроде бы все решили, а потом оказалось, что говорили-то о разном! И одному гуглу известно, сколько человеко-лет сжигается подобным образом: когда кто-то просто захотел использовать термин, который не до конца понимает.

Если вы менеджер и решили использовать в разговоре с программистом одно из этих слов: кеш, блокчейн, микросервисы, АПИ, интерфейс, бэк-енд или клиент, то лучше объясните обычными словами, что вы имеете в виду. Иначе есть большой шанс, что получите вы совсем другое. Да и вообще, с умными словами не перегибайте: даже программисты часто друг друга не понимают, и то, что до сих пор выходят статьи с «простыми» расшифровками SOLID’а, яркий тому пример.

Мир, труд, скрам

Между программистами и менеджерами всегда будут конфликты. Потому что они люди. Люди находили причины съедать сердца друг друга (в буквальном смысле) задолго до изобретения аджайла, и вряд ли эта статья сможет на это повлиять. Однако часто ситуацию можно исправить, изменив наше отношение к ней. Вопрос лишь в желании. Дальше попробую быть корыстным.

Зачем программисту «дружить» с менеджером? Нравится нам это или нет, но берут нас на работу менеджеры (пусть и опосредованно — через других программистов), повышают нам зарплату и увольняют они же. Знать, что они ценят в разработчиках и как строить с ними продуктивные взаимоотношения, — прямой путь к быстрому росту, блестящей карьере и зарплате выше рыночной. Важно понимать, что я не предлагаю лебезить и заискивать перед ними (это уже выбор лично каждого). Я лишь говорю, что с большей вероятностью ты возьмешь на работу приятного тебе человека, который понимает, что ты делаешь и готов в меру своих сил тебе в этом помогать или как минимум не мешать. Его же ты и повысишь и ему же предложишь лишнюю тысячу, чтобы удержать. Поэтому программисту «дружить» с менеджерами очень полезно.

А зачем тогда менеджерам «дружить» с программистами? Потому что менеджер сам ничего не производит. Все успехи менеджера — это успехи его команды и результат ее непосредственной работы. Так что, если люди, которые эту работу делают, тебе симпатизируют и у вас налажена эффективная коммуникация, дело пойдет намного легче и быстрее. Также не стоит забывать, что рынок программистов сейчас очень горяч, и, если ты будешь относиться к своим сотрудникам плохо, они легко найдут другую команду с более адекватным руководством, а вот ты хороших разработчиков будешь искать долго.

Помимо всего этого, есть довольно простая причина жить дружно: так приятней. Ведь круто работать в дружном коллективе, где все друг друга понимают, поддерживают и помогают? Может, я и наивен, но стремиться к этому стоит.

Поэтому закончу цитатой Джима Джеффриса, которая в своей простоте прекрасно суммирует то, к чему я так долго веду: «Try not to be a cunt, and if you do that every day, you’ll be a good person».

Так что будьте good person, а остальное приложится. Ну а если не согласны, пишите в комментариях.

Классных вам проектов и легких апрайзалов! До новых виртуальных встреч!

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось1
До обраногоВ обраному8
LinkedIn

Схожі статті




42 коментарі

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Отличная статья! Спасибо)

Почему везде указано «менеджеры»? Это прямо зеркально обратная картина, когда «менеджеры» не понимают разработчиков... Вы б сразу писали, что «менеджер» — это проектный менеджер (PM), а не «менеджер продукта», «менеджер компании» и т.д. и т.п. (да, развелось их). Ведь нередко как раз и пытаются подружить менеджеров (не PM) с командой разработки. С этого и начинается: кто-то себе позволил что-то отбросить как несущественное, недосказал, другие представили по-другому и началось расхождение — годная основа для «не то на проде». А еще любопытно наблюдать, когда IT BA заменяется «менеджером», да еще и который, по сути, product owner, да еще и глубоко со стороны заказчика. А кто будет мостом между заинтересованными сторонами и разработкой?

с помощью мессенджеров

100%. И лучше все вопросы решать там, чтобы не было потом «вы меня не так поняли» или «я вам этого не говорил». А любителей «пообщаться» приглашать(отсылать) в ФБ.

Потрібна стаття. Стан «та як він посмів таке написати?» переплітався з «100%! хоч хтось розуміє цю ситуацію», а тому намагання привести до спільного знаменника протилежні полюси відчувались. Дещо для себе виніс, отже недаремно витратив час на прочитання. Дякую!

Много букав. Моё мнение: действительно хорошие менеджеры, вышедшие из разработчиков или тестировщиков нужны на проекте. Поскольку программисты по сути своей не только технари, но еще и интроверты, то общение напрямую с заказчиком — это очень плохая идея. Нужен согласующий интерфейс :) Вы же не общаетесь с компьютером полностью и непосредственно в машинных кодах? У вас есть интерфейс ввода-вывода для этого, та же клавиатура с мышкой и монитор, и это только на первом этапе...

— Ну для 5–10 я сделаю за 3 дня, а для 1000 — за месяц.
— Много котов в одной таблице к беде. Делай для 5–10, а там посмотрим.

Да, да, да. Делаешь для 5-10, а потом манагер бежит и спрашивает «ну тут уже же всё работает, давай просто включим для 1000». А ты ему начинаешь про месяц времени, ага.

Поздравляю — у вас не проджект, а саппортер, или сейлз, или еще кто.

Во-первых, огромный разброс по исходным данным в требованиях. Так пара десятков котят или пара тысяч? Откуда эти цифры? Поскольку менеджер живет в вероятностном мире, он видит возможность того, что котят будет именно 1000. Даже если такой человек будет один, а у остального миллиона пользователей будет от 5 до 10 котят. Почему бы не сделать продукт хорошим для всех?

А что услышал программист? Он услышал о лимите в 1000. Но ведь когда он будет писать код, то не сможет только чуть-чуть поддерживать определенный кейс. Его надо будет либо поддерживать, либо нет. Соответственно, он проектирует решение под 1000 котят, хотя в 99% случаев их будет на несколько порядков меньше. Отсюда и месяц.

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

Именно поэтому менеджер с нетехническим бэкграундом — это зло. Не то, чтобы всегда, но на порядок чаще, чем менеджер-технарь.

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

Да , конечно, это правда.

А вы, менеджеры, если хотите быть не погонщиками, а любимыми господами/госпожами, дайте иногда кодерам высказаться.

И все :) ? Тогда высказываться будут вполне однозначно и словами похожими на китайские :) Тут зияет дыра: если манагера дейсно интересует насколько быстро, качественно и надежно програмер напишет код, то манагер (часто не один :) ) должен также прилагать максимум своих усилий, чтобы програмер мог писать код быстро, качественно и надежно. То есть работать не только с людьми вааще, но со своими людьми в частности и в первую очередь.

"Try not to be a cunt, and if you do that every day, you’ll be a good person".

сопсно +100. Будь человеком, и люди к тебе потянуЦЦа.

Классика! Кого уволить первым www.youtube.com/watch?v=hNuu9CpdjIo

А вы, менеджеры, если хотите быть не погонщиками, а любимыми господами/госпожами,

s9.stc.all.kpcdn.net/...​12/6957210/inx960×640.jpg

знов ці потоки...омг..у кожного, з вище перелічених колег, є робота коли він в потоці, але тільки деви завжди ниють про це..ну камон, треба усвідомлювати, що усі ми на роботі а не в школі і що результат і успішність продукту і наша зп залежить від командної роботи то ж

Так что будьте good person, а остальное приложится.

Хоспаді! Вам би для початку на жабах та гадюках потренуватися, а вже потім заглиблюватися у більш екзотичні питання )

Я так и не понял зачем нужны такие менеджеры
Которые не понимают что у них за продукт, что делает программист, как это проверить и как это показать клиенту. Что он вообще знает?
Допустим есть фрилансер, и жнец и швец и он все делает сам. Когда проект больше, снимает одну шляпу и отдаёт шляпу дизайнера другому, дизайнеру, который сделает дизайн быстрее и лучше, плюс ещё кофе с ним выпьет и анекдот расскажет. Когда совсем мало времени, находит ещё одного такого же, уже погроми та, и отдаёт ему шляпу программиста, сам остаётся в шляпе Лида.
Что в такой картине делает менеджер? Читая статью я вижу именно такой образ — человека, который там не нужен и быть его не должно.
Менеджеры с техническим бекграундом это совсем другой зверь, они понимают суть и, если прижимает, могут сами что-то сделать. Просто им проще отдать это тем, кто могет быстрее. А дармоеды скрам мастера это за гранью моего понимания

А кто этому фрилансеру задачи даёт?)

Ізтумбачкі (тм)

Ви зараз прикалуєтесь, чи як? Тіпо девелопер, особливо фрілансер, вже не в змозі зібрати бізнес-вимоги напряму від замовника та конвертувати їх у приоритизовані таски?

Ок, берет напрямую. Проект растёт. Промотаем чуть времени — проекту несколько лет, он выстрелил. Для его успешного развития уже недостаточно просто «чуйки» заказчика или вашей. Нужны исследования рынка, работа с фокус группами, приоритезация, беклог на несколько команд, стратегия, OKR, KPI...

Если это все продолжает делать заказчик — тогда он менеджер. Если вы — то вы.

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

>Нужны исследования рынка, работа с фокус группами, приоритезация, беклог на несколько команд, стратегия, OKR, KPI...

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

а ему уже нужны люди, которые будут давать точечную инфу, в том числе техническую.

Вспомнился пост
Vlad Balin (gaperton) (тех лид)

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

Я слушал, глядя в окно. Помолчал. И говорю.

— Видите, вон там паровоз стоит?
— Где?
— Ну вон, на путях, видно его. На нем делают экскурсии. Можно рядом с вокзалом билет купить.
— Да? Ух ты, как здорово!
— Ага. Паровоз старый, ломается все время, удивительно как они умудряются держать его на ходу. Это делает группа инженеров и техников. Еще есть кочегар и машинист — машинист это редкая по нашим временам профессия. Вокруг этого уникального паровоза, который возит людей, возник бизнес. А вот там — видите — окошко. Туда деньги за билеты заносят. Это сейлз. А вон там — видите, на площади? Человек стоит. Кричит, наверное — «билеты на паровоз, билеты на паровоз»! Маркетинг.
— Ты это к чему?
— К тому, что всю работу, за которую клиенты готовы платить деньги, на самом деле делает вот этот железный паровоз. А все людишки вокруг — его обслуживают. Как ты считаешь, если с паровозом что-то случится, сейлз и маркетинг продолжит зарабатывать деньги?
— Вряд ли.
— А если инженер с техниками вдруг расхотят с ним возиться, потому что на них кто-то решил съэкономить, и уйдут на пенсию — легко-ли будет найти специалистов по этому паровозу? Ну ты вот, например, в общих чертах представляешь, как завести паровоз? Я слышал, это занимает где-то часа четыре.
— Ты хочешь сказать, что наша система — это тот самый паровоз, а программисты — инженеры и техники.
— Ага, очень похоже, — продолжаю любоваться в окно паровозом, — а сейлз и маркетинг — зарабатывающее подразделение. Главные люди там. Вон, видишь — только что заработали что-то, кто-то к будке подошел, денег в нее занес.
— Подожди, ты хочешь сказать, тут у нас что, дураки штоль все?
— Я? — оборачиваюсь, — Нет, я этого не говорил. Просто обратил внимание на замечательный паровоз. Давно хотел на нем прокатиться, все руки никак не доходят. Обожаю стимпанк и паровозы.
— Ладно, хватит уже дурака валять-то.
— Я начальник — я дурак. Могу себе позволить.
(конец)

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

это все — с разного уровня

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

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

Но. Сценарист то написал всю историю. Монтажер имеет возможность компоновать отснятый материал согласно этой истории. Режиссер и вся команда имеют возможность планировать съемки зная что нужно снять по первым абзацам сценария, а что по последним — сразу.

А при разработке ПО нет такого сценария.
Смонтировать потом то что написано — не получится, если оно не было написано для этого.

И в таких условиях работают не только программисты, а и менеджмент
поэтому
если

Для его успешного развития уже недостаточно просто «чуйки» заказчика или вашей.

то конец проекту :)
Именно «чуйка» и двигает проект. Что бизнесовая, в его бизнес перспективах, что техническая, в его реализации.

итого, приходим что в статье поучения джунам программистам и джунам менеджерам :)

Я не согласен с некоторыми вашими утверждениями, но соглашусь, что статья больше для джунов и мидлов с обеих сторон. Впрочем, не вижу в этом ничего плохого :)

не вижу в этом ничего плохого :)

я тоже считаю что статья в целом правильная

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

не только на фрилансе, а нередко и в командах программисту задачи не ставят, а он их берет

когда есть приоритеризированный беклог — программист только уточняет — вот из 3ех — какую взять?

вообще, в статье в массе мест вместо надо добавить к разработчик, программист — начинающий, джуниор

Например

как простая фраза программиста: «А это реально нужно? Без этой маленькой фичи мы все сделаем за день, а с ней — минимум за неделю» — могла бы сэкономить уйму времени и денег, но она просто не звучит.

Так ведь вопрос «А это реально нужно?» и характеризует программиста как синьёра.
Джун, мидл да, такого вопроса не задают. Они еще не поняли что значит «лучший код — это НЕнаписанный код»

так что и ваш вопрос о джунах

А кто этому фрилансеру задачи даёт?

да, джуну нужно — давать задачи. Брать задачи он еще не умеет.

К сожалению, не во все команды можно нанять только сеньоров. Более того, не все сеньоров действительно зрелы и развиты именно в этом контексте — понять продукт, задачу и решить её максимально эффективно. Все мы люди :)

не все сеньоров действительно зрелы и развиты именно в этом контексте — понять продукт, задачу и решить её максимально эффективно.

тогда НЕ надо их называть их синьёрами. Это — мидлы.
Зрелость — и есть краткое описание того что отличает сеньора от мидла.
«Незрелый сеньор» это абсурд, нонсенс, в стиле — «неполовозрелый отец»

Цитата
Matt Briggs: Печально, но факт: абсолютное большинство не только старших разработчиков, но и тимлидов, являются обычными «средними» программистами.
хабр «Ненастоящие сеньор-девелоперы, или почему годы опыта ни о чем не говорят»

К сожалению, не во все команды можно нанять только сеньоров

да. но в уме при обобщении «разработчик» надо держать — не каждый разработчик джуниор.
и, из той же статьи метко

Если у вас нет ни одного старшего разработчика на руководящих позициях, то проект обречен. Команда отличных «середнячков» может завести вас довольно далеко, но дни продукта все равно сочтены. И в финале вас ждет либо сворачивание лавочки, либо рискованные и дорогостоящие переделки. Единственный, кто способен выбрать правильную технологию и платформу — это старший разработчик. Поэтому его отсутствие в проекте с первых дней серьезно вам повредит.
(конец цитаты)

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

Но приемлимость — это почти синоним компромисс. если исполнители вот «такие какие уж есть», то придется сдавать заказчику задачу НЕ в срок, и такого себе качества.

— Заказчик (з): Мне нужны услуги по доставке коробок с нашей продукцией к покупателям.
— Менеджер (м): Да, конечно! У нас огромный автопарк и водители на любой вкус!
— з: Жду завтра для пробной партии в своем складе номер три
— м: оки-доки

— м: Граждане водители (в)! Нам нужно организовать доставку коробок со склада номер три.
— в: Ну, можно. Какие габариты, какой вес?
— м: А вы что, такие дилетанты что не знаете примерный вес и размер груза, который возите?
— в: От спичечного коробка до слона.
— м: Ммм
— в: Да просто надо позвонить и уточнить какие коробки!

— м: Извиняюсь, я не сильно беспокою?
— з: У меня сейчас совещание!
— м: Я только спросить, какие коробки надо завтра будет отвозить?
— з: Красные! (бросает трубку)

— м: Все, я узнал — возить будем красные коробки!
— в: Эээ?
— м: Ну, откройте справочник по коробкам и посмотрите какие габариты и вес у красных!
— в: У нас нет такого справочника!
— м: А у кого он есть?
— в: Чьи коробки — того и справочник!
— м: эээ

— м: Алоэ, это фирма з? Мы тут подрядились перевести красные коробки. Но наши водители такие дилетанты, что понятия не имеют про них. Вы можете выслать нам ваш справочник по коробкам?
— Девачко на ресепшене (д): Ага, давайте адрес — вышлем вам все 10 книг на почту.
— м: Манагер сабака...
— д: Чего вы ругаетесь? Вы мне адрес свой скажите, завтра вам курьер на него бандероль и отправит.
— м: От йолки, а можно сегодня узнать только про габариты красных коробок?
— д: Да, у завскладом.
— м: Соедините пожалуйста.
— д: А у него уже кончился рабочий день и он ушел домой.

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

Заседание совета директоров. Дверь распахивается от пинка ногой.
Вваливается куча грузчиков и они спрашивают, чо грузить-то будем.

Ну да, ну да.

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

Плохим менеджерам все равно, уточню...

мало того, в фразе противоречие, потому что на практике то:

плевать на то, как вы реализуете фичу в техническом плане.
ИЛИ
насколько качественно и надежно вы ее сделаете

так плевать ИЛИ не плевать на «качественно и надежно» ?
«Вот в чем вопрос»

«Качественно и надежно» — сложное понятие, ведь оно зависит от конкретной ситуации.

Если сроки горят, то «качественно и надежно» — одно. Если проект играет в долгую — совсем другое. И тут важно, что менеджер понимает, какие последствия у технических решений, но при этом ему не обязательно понимать их суть.

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

Если сроки горят, то «качественно и надежно» — одно.

ниже написал

Исполнитель не знает и не может знать НАСКОЛЬКО они горят.

И тут важно, что менеджер понимает, какие последствия у технических решений, но при этом ему не обязательно понимать их суть.

так он понимает последствия не понимая сути?

это как?

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

Генерал командует — сделать марш бросок из пункта А в пункт Б. За Х часов По карте.
Ему, там луг залит водой, за Х часов не получится.

Он, да нафиг мне понимать суть! Сказали б что не выйдет за Х часов.

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

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

Не соглашусь. Чем глубокая осведомленность о технических подходах в реализации фичи поможет менеджеру в его работе? Важный нюанс — я подразумеваю, что technical ownership несет лид или другой технический специалист.

Чем глубокая осведомленность о технических подходах в реализации фичи поможет менеджеру в его работе?

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

Эта информация — у менеджера.
А ему — плевать?

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

А насчет перфекционизма — бывают и менеджеры-перфекционисты :)

Да и подобные технические решения обычно проводятся через лида или engineering manager (тот же лид), они способны и технические детали понять, и бизнес контекст выполняемой задачи.

тогда надо оставить только:
Их интересует другое: насколько быстро вы ее сделаете

потому что за качество и надежность отвечает лид или engineering manager.
А менеджер — некомпетентен в этих вопросах, потому что ему — плевать И потому что есть уже ответственные.

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

Чем глубокая осведомленность о технических подходах в реализации фичи поможет менеджеру в его работе?

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

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

Или когда разработчик говорит — «Ну, эту фичу я сделаю за 3 часа». А потом выясняется, что надо альтернуть таблицу на 100млн строк или смигрировать откуда-то куда-то и «ща будет даунтайм пол часа», а нельзя даунтайм, без согласования заранее уж точно.

Или для ответов на вопросы клиентов типа «Почему оно себя так ведет?», которые обычно могли бы отвлекать разработчиков.

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

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

весь остальной текст очевидный и не несет смысловой нагрузки

Хороший summary :)

Ну как бы да. Откровений, переворачивающих мир, там не содержится. Равно как и безапелляционных советов «делайте так потому что скрам это истина в последней инстанции так правильно». Но очевидные, казалось бы, вещи зачастую упускаются из вида в реальной жизни.
В целом статья понравилась и автору респект.

Підписатись на коментарі