Пользователь
0,0
рейтинг
27 октября 2014 в 18:51

Управление → Умей говорить «нет» и умей говорить «да»

GTD*

Умей говорить «нет»


Старший разработчик Валера работает в роли тимлида на большом и важном проекте для большого и важного заказчика. За окном шумит жаркое лето, по пыльным улицам бегут по своим делам прохожие, голуби крутят пируэты в необъятном казахстанском небе. Жизнь прекрасна – пилотный запуск намечен на конец ноября, команда набрала хороший темп и идет по графику. И тут Валера боковым зрением замечает, как на иконке Скайпа появилась желтая точка – кто-то о нем вспомнил и написал сообщение. Это руководитель проекта: «Зайди ко мне…»

Менеджера зовут Ербол и у него для Валеры имеется пренеприятнейшее известие. В компании заказчика сменился исполнительный директор. Он посмотрел на разрабатываемую систему и решил, что она недостаточно безопасна. И теперь он требует использования ЭЦП абсолютно во всех бизнес-процессах с добавлением QR-кодов во все генерируемые документы. И при этом он поставил условие сделать это, не меняя сроков сдачи системы. «Валера, нужно решить проблему и включить дополнительный функционал в поставку. Я уверен, что вы сможете. Вы же профессионалы!» – Ербол озвучил свою позицию.

«Опачки!» – пронеслось в голове у Валеры. Он тут же навскидку прикинул, что новые фичи потребуют примерно три недели работы всей команды. Ведь придется частично переписать движок бизнес-процессов, плюс прикрутить ЭЦП и QR-коды по всей системе. Валера начал судорожно думать, что же ответить своему руководителю.

Наш герой на минуту отвернулся, подумал, потом вернулся в исходную позицию, улыбнулся и сказал: «Да не вопрос, Ербол! Мы успеем. Мы же профессионалы!» Ербол с облегчением вздохнул и еще раз отметил про себя, с какими классными людьми он работает. Валера тоже был рад: он избежал конфликта с руководством и сгладил сложную ситуацию. Тем более мы должны соглашаться с тем, что говорят руководители, ведь так? Они умнее, да и опыта у них больше.

Валера сказал «да» и тем самым взял на себя обязательство. На следующий день Ербол на совещании у заказчика гордо заявил, что они идут навстречу и реализуют новые функции, причем не в ущерб срокам. Исполнительный директор, в свою очередь, написал отчет своему руководству, в котором также заверил всех, что в декабре все смогут начать пользоваться новой и очень безопасной системой. То есть, основываясь на словах Валеры, многие люди начали выстраивать свои планы и обещать что-то другим людям.

И тут начинается самое интересное. Хотя Валера и сказал «Мы же профессионалы!», на самом деле, он повел себя непрофессионально. Дело в том, что профессионал берет на себя обязательства только тогда, когда полностью уверен, что сможет их выполнить. Навряд ли за ту минуту, что он обдумывал решение в кабинете у Ербола, у него в голове родился новый план, где он в деталях понимал, как теперь необходимо построить работу, чтобы реализовать больше функций за то же самое время. Он просто хотел показаться хорошим и не ссориться со своим руководителем.

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

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

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

«Я сразу скажу, что в те же самые сроки мы не сможем реализовать дополнительный функционал. Дай мне один день, и я представлю тебе варианты решения проблемы» – продолжал Валера. Ербол дал добро и Валерий ушел совещаться с командой.

На следующее утро Валера назначил митинг и в положенное время пришел к Ерболу. Вот что он сказал: «Вчера мы сели с командой и оценили новый функционал в 3 недели работы всей команды. Плюс неделя на риски – итого четыре недели. Рисков закладываем не так много, потому что задача известная и мы знаем, как ее делать. Там просто большой объем доработок. Если бы нам пришлось еще изучать технологию, то время на риски увеличилось бы значительно. Таким образом, первый вариант решения проблемы – сдвинуть сроки на четыре недели. Либо возможен другой путь. У нас в плане такой же объем времени заложен на функционал сканирования документов через поточный сканер. Но заказчик говорит, что сами устройства появятся у них только весной. То есть, мы можем исключить поточное сканирование из беклога, а вместо него реализовать новые механизмы безопасности. А сканирование реализовать либо во время поддержки, либо через допсоглашение – это уже как ты договоришься. И тогда мы укладываемся в прежний срок.»

Они посовещались еще полчаса, обговаривая детали, после чего Ербол поехал к заказчику. Там разговор прошел на удивление легко и был согласован вариант с исключением из графика функции поточного сканирования и переносом ее реализации на зиму.

Счастливый Ербол ехал на такси в офис и думал о том, как хорошо, что в их компании работают такие профессионалы.

Умей говорить «да»


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

После совещания у заказчика, на котором был согласован вариант с заменой поточного сканирования на дополнительные функции безопасности, Ербол снова встретился с Валерой. Он рассказал ему о принятом решении и, на всякий случай, спросил: «Теперь мы это сделаем и уложимся в прежний срок?» «Да, уложимся» — ответил Валера. Мы теперь знаем, что Валера – профессионал. И его ответ показывает нам, что профессионалы также должны уметь говорить «да». Сказав это магическое слово, они берут на себя ответственность за то, что это будет сделано.

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

Валера поговорил с сисадминами и узнал, что проблема кроется в Wi-Fi-роутере, который не мог поддерживать большое количество соединений одновременно. Валера очень хотел решить данную проблему и после обеда встретился с одним из системных администраторов по имени Виктор. Он описал ситуацию и спросил, можно ли ее исправить. «Да, нужно поменять роутер» – ответил Витя.

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

  1. Нужно сказать, что вы сделаете что-то.
  2. Нужно действительно намереваться сделать что-то.
  3. Нужно это сделать.

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

Валера понял это по слову «надо», которое употребил Виктор. Существуют слова-индикаторы, которые применяются, когда человек вроде как признает что-то, но в то же время не берет на себя ответственность. В их число входят: «надо/нужно», «надеюсь», «давайте». Например: «Надо начать ходить в спортзал», «Нужно сесть на диету и начать худеть», «Давайте будем использовать TDD в следующей итерации». Человек говорит об этом, но не планирует это делать. Обычно, эти фразы произносятся и забываются через 5-7 минут. Ответ Вити оказался из той же категории.

Если бы Валера не был профессионалом, он бы довольствовался полученным ответом и ушел. Но он решил продолжить разговор, чтобы Витя четко сказал, кто и когда решит проблему. «Ты решишь эту проблему и поменяешь роутер к среде?» – спросил Валера. «У меня много дел, нужно провести ревизию наших СХД и написать отчет руководству. Поэтому к среде не успею. Предлагаю такой выход: я пока запущу процесс покупки роутера, а в четверг установлю его в кабинете» – ответил Витя.

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

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

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

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

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

Продолжение следует...

P.S. Большую часть идей, описанных в этой статье, я почерпнул из книги Роберта Мартина «Идеальный программист». Они наложились на мой собственный опыт, и в итоге я решил рассказать об этом в виде небольшой вымышленной истории.
Дмитрий Мельник @mitro
карма
43,2
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Управление

Комментарии (34)

  • +17
    Хорошо написано и проблемы очень жизненные, без заумствований. Продолжайте :)
    • +15
      Спасибо, буду по мере возможности описывать дальнейшие приключения Валеры :)
      • 0
        Ждем с нетерпением!!! К слову, можно такие статьи давать читать новым сотрудникам. Чтобы предварительно думали над ответами вышестоящему начальству, а то ведь последствия необдуманного ответа коснутся всех, так или иначе.
  • +5
    Интересный рассказ, жаль не в пятницу, ибо мысли о манагерах с неотъемлемыми индикаторами не улетучиваются в расслабленной дымке «апошливывсе».

    Ербол… Жаль это не фамилия, а то как бы выглядели служебные письма за подписью, скажем, Фарида Ахмедовича :)
    • +11
      Ф.А.Ербол. Только сейчас понял шутку :) Кстати, в Казахстане есть такие фамилии. Сейчас многие отказываются от суффиксов -ов, -ев.
      • 0
        Извините :)

  • +5
    Как бы очевидные вещи, но вспомнить о них еще раз несомненно полезно.
    Не забудьте про продолжение.
    • +7
      У Валеры и его команды бурная жизнь, поэтому продолжение будет :)
  • +3
    Правильные вещи говорите. Так и надо учить. Вот только не забыть добавить, что мир не черно-белый, а «да» или «нет» Валеры зависят не только от профессионализма и мудрого руководства проектами. Иначе есть ненулевой шанс, что крутой профессионал Валера и его команда останутся образно говоря без работы, пару раз круто сказав профессиональное «нет», на что проект образно уйдет индусам и прочим китайцам, о «йес-мэнстве» которых ходят легенды. Т.е. профессиональный ответ — это хорошо, но иногда заказчику надо сказать «да» (или «нет») по политическим, бюджетным и прочим мотивам.
    • +1
      Да, согласен с вами. В рассказе описывается что-то вроде идеала, который нужно держать в уме, принимая какие-то решения. Но он не всегда достижим — жизнь сложная штука. Еще следует сказать, что советы применимы и к процессам внутри компании. Как в истории с роутером. И чем больше людей так себя будут вести, тем эффективнее будет работа.
    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        О том и разговор: «Так проблему не решить» часто проигрывает «Не боись, чувак, сделаем в лучшем виде!». Для пессимистичного или оптимистичного прогноза одного профессионализма мало. Есть еще факторы.
  • +2
    Да, всё верно… Но вот вспоминается мне случай из моего опыта. Начальник на предварительных переговорах с клиентами вот именно так «непрофессионально» сказал «да» в ответ на вопрос клиента, сможем ли мы сделать требуемую работу. Сказал от балды, не посоветовавшись с командой, и в результате… мы получили заказ. Да, обязательства были явно авантюрными; да, в результате были авралы, и код с костылями, и куча недоделок… Да, всё так. Только вот если бы он тогда поступил профессионально и сказал «нет», заказа у нас вообще бы не было.
    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        Это очень и очень зависит от обстоятельств. Команда, в которой я тогда работал, занималась построением виртуальных миров. Заказы большие, но их очень немного, и пропуск заказа мог бы обернуться потерей команды.
  • +2
    Именно так и должно быть. Еще можно добавить про периодический контроль выполнения задачи. Пока ты подчиненный, тебя раздражают такие начальники: ставят конкретную задачу, заставляют четко отвечать на вопросы, постоянно до срока спрашивают, ну когда же, когда? И даже из отпуска им неимется — звонят, спрашивают. А уже когда сам становишься руководителем, то понимаешь, что только так можно достичь гарантированного результата.
    Но что происходит, если так не делать? А просто: директор сказал начальнику отдела, начальник отдела — начальнику сектора, тот подчиненным, а те забыли. И все дальше спят на работе, меняя 8 часов на рубль. И случилось так, что раньше срока никто не вспомнил проверить: как же там прогресс? Наступает час Х: директор спрашивает нач. отд, тот нач сектора, а там ничего не готово. Дальше все начинают «делать свою работу»: задача не решена, по цепочке друг друга поругали, полишали премии. НО остаются вопросы: где результат? кто виноват в том, что его нет?
    Вроде бы говорю очевидные вещи, но: начальник, который ставит задачи и сроки — это очень удобно. Он не даст забыть про задачу, если задач несколько — правильно расставит приоритеты. Потому что это правильно. Сроки сдвигаются — сразу сообщаем начальнику, он на своем уровне решает этот вопрос.
    И еще нельзя лишать свое начальство его законного права: решать проблемы на своем уровне. Пример: пожар на производстве, хоть 3 часа ночи — звоним директору и сообщаем.
  • +1
    Хорошая статья. Толковый менеджер всегда готов слышать правду, какой бы она ни была. Ведь проблемы как болячка, чем раньше диагностируешь, тем проще отделаешься. А вот вторую историю отлично резюмирует пословица «люди делают не то, что ожидаешь, а то, что проверяешь». Свое время вычитанная в какой-то книге по менеджменту, она спасла немало нервов.
  • 0
    похоже на «Clean Coder» Дяди Боба
  • +5
    Тут проблема не в «Да» или «Нет», а в адекватной оценке сроков и ресурсов. Мы могём хоть в космос полететь, хоть ОС написать — дайте только мне людей и денег время. Как правило ресурсы ограничены твоей командой — от этого и будем отталкиваться.

    Ок, ты профи, у тебя за плечами опыт и много завершенных проектов, ты прекрасно можешь оценить сроки с учетом доступных ресурсов. А вот дальше начинается самая веселуха. Давайте упростим ситуацию — задачу ставит менеджер проекта. Менеджер тоже «профи», он хочет услышать от тебя конкретную цифру по срокам, чтобы в уме ее умножить на два (он тоже «профи» — учитывает все риски). Но если ты реально имеешь опыт, то не можешь дать точную цифру для абстрактной задачи (например как в статье). На вскидку ты можешь определить срок с точностью (внимание!) -80%...+400%!!! Если озвучить эти цифры неподготовленному к ним менеджеру, им это будет воспринято даже не как показатель вашей некомпетентности, а как жесткий троллинг. Я конечно понимаю, менеджеры на то и созданы, чтобы над ними стебаться, но и задачи как-то надо решать.

    На самом деле все просто. Нужно вбить в голову себе, менеджерам, руководству и подчиненным, что оценка сроков не всегда тривиальная задача. У вас наверняка найдется пара проектов, где очень похожие «внешне» задачи решались в одном случае добавлением пару строк кода, а в другом перелопачиванием всей системы, который можно привести в пример. Но и здесь нужно уметь держать контрудар — а почему элементарную функциональность может быть внести так тяжело? Любой проект — это поиск компромиссов, между гибкостью, производительностью и сроками разработки. Ок, мы сделаем то-то и то-то в два раза быстрее, но с добавлением того или иного функционала будут проблемы. Цепочка таких компромиссов может быть очень длинной, а начальство очень быстро об этом забывает (да и вы сами) поэтому важно все фиксировать.

    Поэтому оценка сроков, любой нетривиальной задачи (а это уже вам решать насколько она тривиальная), требует постановки задачи на оценку сроков. И здесь не все так просто, те же -80%...+400%. Можно зафиксировать для себя верхний предел, допустим 4 часа. Т.е. буквально от нескольких минут до 4-х часов. Если вы не укладываетесь в верхний предел, то тут понятно задача далеко не тривиальна, и на дополнительную оценку нужно просить несколько дней. Уже на этом этапе отсеивается 80% «гениальных» идей типа «давайте сделаем и посмотрим, попрет или нет».

    Важность формальной постановки задачи еще в том, что на словах менеджер имеет ввиду, например простой checkbox, а в уме представляет себе всплывающую подсказку, за информацией для которой надо лезть черти куда (ну это так для примера, IU я не проектировал ни разу). Т.е. должна быть обратная связь, чтобы понять, что конкретно он имеет ввиду.

    Ну и наконец, ты же не быдло-тимлид, чтобы тупо взять задачу, оценить сроки и взять в разработку. Любое «все» можно поделить на 80/20 (или 90/10 или по «золотому сечению», не важно). Нужно быть ленивым и меркантильным (не в плане денег, разумеется). Ок, 80% функционала мы сделаем за неделю, на остальные 20% нужен месяц — а так ли он вам нужен? В 80% он оказывается не особо то и нужным.

    Еще один важный момент. Руководство хочет получить конкретную дату, когда проект будет готов, а ты реально можешь оценить сроки в человеко-часах. Опять же с большой погрешностью, может и не в соотношении 80/20, но все же большой. Погрешность примет адекватные очертания после 25%..50% реализации функционала. Ответ простой — ребят, вы отвечаете за разработку, внешние факторы не в вашей компетенции. Отдел тестирования завален работой, менеджеры тупят с уточнением по задачи, у админов факап — это не ваши проблемы, абсолютно. На это есть руководители проекта, менеджеры и пр. Не надо брать на себя их работу. Тем более, возможно, кому-то и платят больше чем вам.

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

    Итого. Если ты не быдло-кодер, быдло-менеджер, быдло-тимлид, быдло-гендир, то в любом случае должен иметь смелость откровенно общаться со своим непосредственным начальством. Предельно деликатно, без хамства, наездов, без доказательств чей-то (не)компетентности, но аргументировано и развернуто. Если ты держишься за свое место, у тебя дети, жена, ипотека, теща, больная бабушка, съемная квартира, холодильник в кредит и пр. отмазки — то поздравляю = ты неудачник ))
    • 0
      Строго говоря вы правы. Валера должен был притащить Виктора к Ерболу и заставить их разработать план по наладке сети. Не Валерина компетенция решать проблемы внутренней инфраструктуры.
      Что касается итеративной разработки — у неё есть свои особенности:
      Во-1, архитектурные риски. В конце проекта может возникнуть требование, которое несовместимо с выбранной вначале архитектурой.
      Во-2, Поддержание продукта «в компилируемой форме» требует некоторых добавочных ресурсов, что может не соответствовать графику финансирования «25% предоплаты и 75% финальной оплаты».
      Хотя, согласен, сейчас итеративная мне видится как наименее худшая.
      По поводу 4 часового лимита на мозговой штурм я не согласен. Постоянно натыкаюсь на оптимистов, которые за 7 минут на словах раскидывают задачку на две недели «в худшем случае» и не могут внятно разрисовать план фактических действий даже на A4 бумажке в течение полугода.
  • +1
    QR-коды в документах это отличная мысль! Спасибо. И за статью в целом.
  • 0
    Пример с роутером показателен. Неделя с хвостиком на замену роутера — это как раз как НЕ «должен работать технический отдел большой и современной IT-компании».
    К сожалению — это типичная ситуация для больших компаний, когда на бюрократию уходит время и силы. Знаю случаи, когда мышку работникам неделями меняли, или картридж в принтере.
    • 0
      Ну а почему нет?
      В «переговорной» когда-то сделали гостевой Wi-Fi, а тут, вдруг, надо обеспечить там полноценную работу в облаке.
      • 0
        И, кстати, Виктору не факт, что про облако говорили — поставит чуть менее лагающий Wi-Fi с мыслью, что для вКонтактика разработчикам хватит. Не надо «Валере-профессионалу» собственных расследований устраивать и в испорченный телефон между сисадминами играть.
  • +2
    Понравилось!
    Про умение сказать «нет» написано много, про вторую часть — редко пишут.
    Вторую часть можно было бы переименовать «как правильно получить ответ „ДА“?
    • 0
      «Как правильно получить ответ Да» — и это тоже. Но в первую очередь это о том, что люди должны понимать, какую ответственность они берут на себя, говоря «да».
  • +3
    Хоть ссылку кидай своему «Ерболу», который каждый раз обещает все, не советуясь с командой.
    И наш «Валера», к слову, тоже не умеет отказывать.
  • 0
    В вашем хеппи-эндовском варианте Валера взял время на оценку, Валера провел совещание, Валера выдал оценку, Валера предусмотрел риски, Валера в курсе внутренней кухни заказчика (т.е. проблеме поставки сканеров), Валера занимается планированием проекта.
    Ок, Валера — профессионал.
    Но зачем тогда на проекте Ербол? Передаточное звено?
    Ясное дело, что оценка новой задачи должна идти снизу.
    Но если менеджер не знает всего объема работ, не знает о зависимости между работами (в частности, между разработкой сканирования и поставкой сканеров), и сам не может додуматься, что можно поменять приоритеты задач — такой менеджер не нужен.
    • 0
      К сожалению, такие менеджеры все еще встречаются в нашей индустрии. С этим надо жить. И если работать по принципу «Ты начальник, ты и решай свои вопросы», то можно отхватить больше проблем, нежели в случае, когда каждый пытается подстраховать друг друга.
    • 0
      Менеджер должен управлять ожиданиями Клиента, это его основная роль. Он защищает Команду от Клиента, т.к. если бы Валера общался с Клиентом напрямую, в некоторых случаях у него на переписку и звонки уходило бы до 50% рабочего времени. А еще хороший менеджер — это немножко Customer Care. Этакая мамка для Клиента (и для Команды тоже), которая всех успокоит и решит любой вопрос полюбовно, хорошо разобравшись в ситуации.
      Такой менеджер может не знать и не должен знать тонкостей, он не может точно или даже примерно определить масштабы доработок и их влияние на сроки и бюджет. Для этого есть технический лидер проекта, в обязанности которого входит быстрая и качественная экспертная оценка, чтобы при возникновении у Клиента Гениальной Идеи быстро и точно оценить как это помешает достижению поставленных целей.
      Конечно, менеджер должен уметь отсеивать откровенный треш, но любые манипуляции с пулом задач должны исходить от технического лидера, а не от менеджера. Либо как минимум верифицироваться у него, т.к. в любой разработке всегда куча тонкостей.
  • 0
    Еесть очень интересный курс Model Thinking
    Там в том числе есть и модели человеческого поведения. Так вот, суть такая что человеческое поведение можно разделить на три основных модели:
    — рациональная (выгода, логика, объективность) — обычно занимает больше времени на принятие решения
    — поведенческая (эмоции, интуиция)
    — основанная на правилах

    Валера в начале истории, когда взял на себя невыполнимые обязательства по проекту действовал в рамках поведенческой модели поведения, и частично в рамках правил («нельзя говорит нет руководству»).
    А как мы выяснили позже единственное верное решение можно принять только используя рациональную модель поведения, не смотря на то что она требует от нас больше времени и ментальных усилий здесь и сейчас, это единственная модель которая поможет в итоге остаться в выигрыше.
    • 0
      Интересная информация, спасибо за ссылку.
  • +1
    Читая статью, сразу вспомнилась книга Роберта Мартина, интересная интерпретация, спасибо :)
    • 0
      Спасибо за отзыв! Я постарался изложит кратко и в необычной форме. Считаю, такой способ подачи весьма эффективным.

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