Comments 34
Хорошо написано и проблемы очень жизненные, без заумствований. Продолжайте :)
Интересный рассказ, жаль не в пятницу, ибо мысли о манагерах с неотъемлемыми индикаторами не улетучиваются в расслабленной дымке «апошливывсе».
Ербол… Жаль это не фамилия, а то как бы выглядели служебные письма за подписью, скажем, Фарида Ахмедовича :)
Ербол… Жаль это не фамилия, а то как бы выглядели служебные письма за подписью, скажем, Фарида Ахмедовича :)
Как бы очевидные вещи, но вспомнить о них еще раз несомненно полезно.
Не забудьте про продолжение.
Не забудьте про продолжение.
Правильные вещи говорите. Так и надо учить. Вот только не забыть добавить, что мир не черно-белый, а «да» или «нет» Валеры зависят не только от профессионализма и мудрого руководства проектами. Иначе есть ненулевой шанс, что крутой профессионал Валера и его команда останутся образно говоря без работы, пару раз круто сказав профессиональное «нет», на что проект образно уйдет индусам и прочим китайцам, о «йес-мэнстве» которых ходят легенды. Т.е. профессиональный ответ — это хорошо, но иногда заказчику надо сказать «да» (или «нет») по политическим, бюджетным и прочим мотивам.
Да, согласен с вами. В рассказе описывается что-то вроде идеала, который нужно держать в уме, принимая какие-то решения. Но он не всегда достижим — жизнь сложная штука. Еще следует сказать, что советы применимы и к процессам внутри компании. Как в истории с роутером. И чем больше людей так себя будут вести, тем эффективнее будет работа.
UFO just landed and posted this here
Да, всё верно… Но вот вспоминается мне случай из моего опыта. Начальник на предварительных переговорах с клиентами вот именно так «непрофессионально» сказал «да» в ответ на вопрос клиента, сможем ли мы сделать требуемую работу. Сказал от балды, не посоветовавшись с командой, и в результате… мы получили заказ. Да, обязательства были явно авантюрными; да, в результате были авралы, и код с костылями, и куча недоделок… Да, всё так. Только вот если бы он тогда поступил профессионально и сказал «нет», заказа у нас вообще бы не было.
Именно так и должно быть. Еще можно добавить про периодический контроль выполнения задачи. Пока ты подчиненный, тебя раздражают такие начальники: ставят конкретную задачу, заставляют четко отвечать на вопросы, постоянно до срока спрашивают, ну когда же, когда? И даже из отпуска им неимется — звонят, спрашивают. А уже когда сам становишься руководителем, то понимаешь, что только так можно достичь гарантированного результата.
Но что происходит, если так не делать? А просто: директор сказал начальнику отдела, начальник отдела — начальнику сектора, тот подчиненным, а те забыли. И все дальше спят на работе, меняя 8 часов на рубль. И случилось так, что раньше срока никто не вспомнил проверить: как же там прогресс? Наступает час Х: директор спрашивает нач. отд, тот нач сектора, а там ничего не готово. Дальше все начинают «делать свою работу»: задача не решена, по цепочке друг друга поругали, полишали премии. НО остаются вопросы: где результат? кто виноват в том, что его нет?
Вроде бы говорю очевидные вещи, но: начальник, который ставит задачи и сроки — это очень удобно. Он не даст забыть про задачу, если задач несколько — правильно расставит приоритеты. Потому что это правильно. Сроки сдвигаются — сразу сообщаем начальнику, он на своем уровне решает этот вопрос.
И еще нельзя лишать свое начальство его законного права: решать проблемы на своем уровне. Пример: пожар на производстве, хоть 3 часа ночи — звоним директору и сообщаем.
Но что происходит, если так не делать? А просто: директор сказал начальнику отдела, начальник отдела — начальнику сектора, тот подчиненным, а те забыли. И все дальше спят на работе, меняя 8 часов на рубль. И случилось так, что раньше срока никто не вспомнил проверить: как же там прогресс? Наступает час Х: директор спрашивает нач. отд, тот нач сектора, а там ничего не готово. Дальше все начинают «делать свою работу»: задача не решена, по цепочке друг друга поругали, полишали премии. НО остаются вопросы: где результат? кто виноват в том, что его нет?
Вроде бы говорю очевидные вещи, но: начальник, который ставит задачи и сроки — это очень удобно. Он не даст забыть про задачу, если задач несколько — правильно расставит приоритеты. Потому что это правильно. Сроки сдвигаются — сразу сообщаем начальнику, он на своем уровне решает этот вопрос.
И еще нельзя лишать свое начальство его законного права: решать проблемы на своем уровне. Пример: пожар на производстве, хоть 3 часа ночи — звоним директору и сообщаем.
Хорошая статья. Толковый менеджер всегда готов слышать правду, какой бы она ни была. Ведь проблемы как болячка, чем раньше диагностируешь, тем проще отделаешься. А вот вторую историю отлично резюмирует пословица «люди делают не то, что ожидаешь, а то, что проверяешь». Свое время вычитанная в какой-то книге по менеджменту, она спасла немало нервов.
похоже на «Clean Coder» Дяди Боба
Тут проблема не в «Да» или «Нет», а в адекватной оценке сроков и ресурсов. Мы могём хоть в космос полететь, хоть ОС написать — дайте только мне людей и денег время. Как правило ресурсы ограничены твоей командой — от этого и будем отталкиваться.
Ок, ты профи, у тебя за плечами опыт и много завершенных проектов, ты прекрасно можешь оценить сроки с учетом доступных ресурсов. А вот дальше начинается самая веселуха. Давайте упростим ситуацию — задачу ставит менеджер проекта. Менеджер тоже «профи», он хочет услышать от тебя конкретную цифру по срокам, чтобы в уме ее умножить на два (он тоже «профи» — учитывает все риски). Но если ты реально имеешь опыт, то не можешь дать точную цифру для абстрактной задачи (например как в статье). На вскидку ты можешь определить срок с точностью (внимание!) -80%...+400%!!! Если озвучить эти цифры неподготовленному к ним менеджеру, им это будет воспринято даже не как показатель вашей некомпетентности, а как жесткий троллинг. Я конечно понимаю, менеджеры на то и созданы, чтобы над ними стебаться, но и задачи как-то надо решать.
На самом деле все просто. Нужно вбить в голову себе, менеджерам, руководству и подчиненным, что оценка сроков не всегда тривиальная задача. У вас наверняка найдется пара проектов, где очень похожие «внешне» задачи решались в одном случае добавлением пару строк кода, а в другом перелопачиванием всей системы, который можно привести в пример. Но и здесь нужно уметь держать контрудар — а почему элементарную функциональность может быть внести так тяжело? Любой проект — это поиск компромиссов, между гибкостью, производительностью и сроками разработки. Ок, мы сделаем то-то и то-то в два раза быстрее, но с добавлением того или иного функционала будут проблемы. Цепочка таких компромиссов может быть очень длинной, а начальство очень быстро об этом забывает (да и вы сами) поэтому важно все фиксировать.
Поэтому оценка сроков, любой нетривиальной задачи (а это уже вам решать насколько она тривиальная), требует постановки задачи на оценку сроков. И здесь не все так просто, те же -80%...+400%. Можно зафиксировать для себя верхний предел, допустим 4 часа. Т.е. буквально от нескольких минут до 4-х часов. Если вы не укладываетесь в верхний предел, то тут понятно задача далеко не тривиальна, и на дополнительную оценку нужно просить несколько дней. Уже на этом этапе отсеивается 80% «гениальных» идей типа «давайте сделаем и посмотрим, попрет или нет».
Важность формальной постановки задачи еще в том, что на словах менеджер имеет ввиду, например простой checkbox, а в уме представляет себе всплывающую подсказку, за информацией для которой надо лезть черти куда (ну это так для примера, IU я не проектировал ни разу). Т.е. должна быть обратная связь, чтобы понять, что конкретно он имеет ввиду.
Ну и наконец, ты же не быдло-тимлид, чтобы тупо взять задачу, оценить сроки и взять в разработку. Любое «все» можно поделить на 80/20 (или 90/10 или по «золотому сечению», не важно). Нужно быть ленивым и меркантильным (не в плане денег, разумеется). Ок, 80% функционала мы сделаем за неделю, на остальные 20% нужен месяц — а так ли он вам нужен? В 80% он оказывается не особо то и нужным.
Еще один важный момент. Руководство хочет получить конкретную дату, когда проект будет готов, а ты реально можешь оценить сроки в человеко-часах. Опять же с большой погрешностью, может и не в соотношении 80/20, но все же большой. Погрешность примет адекватные очертания после 25%..50% реализации функционала. Ответ простой — ребят, вы отвечаете за разработку, внешние факторы не в вашей компетенции. Отдел тестирования завален работой, менеджеры тупят с уточнением по задачи, у админов факап — это не ваши проблемы, абсолютно. На это есть руководители проекта, менеджеры и пр. Не надо брать на себя их работу. Тем более, возможно, кому-то и платят больше чем вам.
Итеративная разработка. Клевая штука, и не важно какую методологию вы используете, но при 20-25% процентах готовности у вас должен быт работающий прототип системы, который можно «пощупать» и даже отдать на тестирование. Как привило, начальство, не старые пердуны, которые кроме как про водопадную модель ничего не знают. Просто надо деликатно напомнить (даже если об этом и не спрашивают), то что «это» даже если и работает, то основная работа еще впереди, которая подразумевает не просто навешивание «рюшечек».
Итого. Если ты не быдло-кодер, быдло-менеджер, быдло-тимлид, быдло-гендир, то в любом случае должен иметь смелость откровенно общаться со своим непосредственным начальством. Предельно деликатно, без хамства, наездов, без доказательств чей-то (не)компетентности, но аргументировано и развернуто. Если ты держишься за свое место, у тебя дети, жена, ипотека, теща, больная бабушка, съемная квартира, холодильник в кредит и пр. отмазки — то поздравляю = ты неудачник ))
Ок, ты профи, у тебя за плечами опыт и много завершенных проектов, ты прекрасно можешь оценить сроки с учетом доступных ресурсов. А вот дальше начинается самая веселуха. Давайте упростим ситуацию — задачу ставит менеджер проекта. Менеджер тоже «профи», он хочет услышать от тебя конкретную цифру по срокам, чтобы в уме ее умножить на два (он тоже «профи» — учитывает все риски). Но если ты реально имеешь опыт, то не можешь дать точную цифру для абстрактной задачи (например как в статье). На вскидку ты можешь определить срок с точностью (внимание!) -80%...+400%!!! Если озвучить эти цифры неподготовленному к ним менеджеру, им это будет воспринято даже не как показатель вашей некомпетентности, а как жесткий троллинг. Я конечно понимаю, менеджеры на то и созданы, чтобы над ними стебаться, но и задачи как-то надо решать.
На самом деле все просто. Нужно вбить в голову себе, менеджерам, руководству и подчиненным, что оценка сроков не всегда тривиальная задача. У вас наверняка найдется пара проектов, где очень похожие «внешне» задачи решались в одном случае добавлением пару строк кода, а в другом перелопачиванием всей системы, который можно привести в пример. Но и здесь нужно уметь держать контрудар — а почему элементарную функциональность может быть внести так тяжело? Любой проект — это поиск компромиссов, между гибкостью, производительностью и сроками разработки. Ок, мы сделаем то-то и то-то в два раза быстрее, но с добавлением того или иного функционала будут проблемы. Цепочка таких компромиссов может быть очень длинной, а начальство очень быстро об этом забывает (да и вы сами) поэтому важно все фиксировать.
Поэтому оценка сроков, любой нетривиальной задачи (а это уже вам решать насколько она тривиальная), требует постановки задачи на оценку сроков. И здесь не все так просто, те же -80%...+400%. Можно зафиксировать для себя верхний предел, допустим 4 часа. Т.е. буквально от нескольких минут до 4-х часов. Если вы не укладываетесь в верхний предел, то тут понятно задача далеко не тривиальна, и на дополнительную оценку нужно просить несколько дней. Уже на этом этапе отсеивается 80% «гениальных» идей типа «давайте сделаем и посмотрим, попрет или нет».
Важность формальной постановки задачи еще в том, что на словах менеджер имеет ввиду, например простой checkbox, а в уме представляет себе всплывающую подсказку, за информацией для которой надо лезть черти куда (ну это так для примера, IU я не проектировал ни разу). Т.е. должна быть обратная связь, чтобы понять, что конкретно он имеет ввиду.
Ну и наконец, ты же не быдло-тимлид, чтобы тупо взять задачу, оценить сроки и взять в разработку. Любое «все» можно поделить на 80/20 (или 90/10 или по «золотому сечению», не важно). Нужно быть ленивым и меркантильным (не в плане денег, разумеется). Ок, 80% функционала мы сделаем за неделю, на остальные 20% нужен месяц — а так ли он вам нужен? В 80% он оказывается не особо то и нужным.
Еще один важный момент. Руководство хочет получить конкретную дату, когда проект будет готов, а ты реально можешь оценить сроки в человеко-часах. Опять же с большой погрешностью, может и не в соотношении 80/20, но все же большой. Погрешность примет адекватные очертания после 25%..50% реализации функционала. Ответ простой — ребят, вы отвечаете за разработку, внешние факторы не в вашей компетенции. Отдел тестирования завален работой, менеджеры тупят с уточнением по задачи, у админов факап — это не ваши проблемы, абсолютно. На это есть руководители проекта, менеджеры и пр. Не надо брать на себя их работу. Тем более, возможно, кому-то и платят больше чем вам.
Итеративная разработка. Клевая штука, и не важно какую методологию вы используете, но при 20-25% процентах готовности у вас должен быт работающий прототип системы, который можно «пощупать» и даже отдать на тестирование. Как привило, начальство, не старые пердуны, которые кроме как про водопадную модель ничего не знают. Просто надо деликатно напомнить (даже если об этом и не спрашивают), то что «это» даже если и работает, то основная работа еще впереди, которая подразумевает не просто навешивание «рюшечек».
Итого. Если ты не быдло-кодер, быдло-менеджер, быдло-тимлид, быдло-гендир, то в любом случае должен иметь смелость откровенно общаться со своим непосредственным начальством. Предельно деликатно, без хамства, наездов, без доказательств чей-то (не)компетентности, но аргументировано и развернуто. Если ты держишься за свое место, у тебя дети, жена, ипотека, теща, больная бабушка, съемная квартира, холодильник в кредит и пр. отмазки — то поздравляю = ты неудачник ))
Строго говоря вы правы. Валера должен был притащить Виктора к Ерболу и заставить их разработать план по наладке сети. Не Валерина компетенция решать проблемы внутренней инфраструктуры.
Что касается итеративной разработки — у неё есть свои особенности:
Во-1, архитектурные риски. В конце проекта может возникнуть требование, которое несовместимо с выбранной вначале архитектурой.
Во-2, Поддержание продукта «в компилируемой форме» требует некоторых добавочных ресурсов, что может не соответствовать графику финансирования «25% предоплаты и 75% финальной оплаты».
Хотя, согласен, сейчас итеративная мне видится как наименее худшая.
По поводу 4 часового лимита на мозговой штурм я не согласен. Постоянно натыкаюсь на оптимистов, которые за 7 минут на словах раскидывают задачку на две недели «в худшем случае» и не могут внятно разрисовать план фактических действий даже на A4 бумажке в течение полугода.
Что касается итеративной разработки — у неё есть свои особенности:
Во-1, архитектурные риски. В конце проекта может возникнуть требование, которое несовместимо с выбранной вначале архитектурой.
Во-2, Поддержание продукта «в компилируемой форме» требует некоторых добавочных ресурсов, что может не соответствовать графику финансирования «25% предоплаты и 75% финальной оплаты».
Хотя, согласен, сейчас итеративная мне видится как наименее худшая.
По поводу 4 часового лимита на мозговой штурм я не согласен. Постоянно натыкаюсь на оптимистов, которые за 7 минут на словах раскидывают задачку на две недели «в худшем случае» и не могут внятно разрисовать план фактических действий даже на A4 бумажке в течение полугода.
QR-коды в документах это отличная мысль! Спасибо. И за статью в целом.
Пример с роутером показателен. Неделя с хвостиком на замену роутера — это как раз как НЕ «должен работать технический отдел большой и современной IT-компании».
К сожалению — это типичная ситуация для больших компаний, когда на бюрократию уходит время и силы. Знаю случаи, когда мышку работникам неделями меняли, или картридж в принтере.
К сожалению — это типичная ситуация для больших компаний, когда на бюрократию уходит время и силы. Знаю случаи, когда мышку работникам неделями меняли, или картридж в принтере.
Понравилось!
Про умение сказать «нет» написано много, про вторую часть — редко пишут.
Вторую часть можно было бы переименовать «как правильно получить ответ „ДА“?
Про умение сказать «нет» написано много, про вторую часть — редко пишут.
Вторую часть можно было бы переименовать «как правильно получить ответ „ДА“?
Хоть ссылку кидай своему «Ерболу», который каждый раз обещает все, не советуясь с командой.
И наш «Валера», к слову, тоже не умеет отказывать.
И наш «Валера», к слову, тоже не умеет отказывать.
В вашем хеппи-эндовском варианте Валера взял время на оценку, Валера провел совещание, Валера выдал оценку, Валера предусмотрел риски, Валера в курсе внутренней кухни заказчика (т.е. проблеме поставки сканеров), Валера занимается планированием проекта.
Ок, Валера — профессионал.
Но зачем тогда на проекте Ербол? Передаточное звено?
Ясное дело, что оценка новой задачи должна идти снизу.
Но если менеджер не знает всего объема работ, не знает о зависимости между работами (в частности, между разработкой сканирования и поставкой сканеров), и сам не может додуматься, что можно поменять приоритеты задач — такой менеджер не нужен.
Ок, Валера — профессионал.
Но зачем тогда на проекте Ербол? Передаточное звено?
Ясное дело, что оценка новой задачи должна идти снизу.
Но если менеджер не знает всего объема работ, не знает о зависимости между работами (в частности, между разработкой сканирования и поставкой сканеров), и сам не может додуматься, что можно поменять приоритеты задач — такой менеджер не нужен.
К сожалению, такие менеджеры все еще встречаются в нашей индустрии. С этим надо жить. И если работать по принципу «Ты начальник, ты и решай свои вопросы», то можно отхватить больше проблем, нежели в случае, когда каждый пытается подстраховать друг друга.
Менеджер должен управлять ожиданиями Клиента, это его основная роль. Он защищает Команду от Клиента, т.к. если бы Валера общался с Клиентом напрямую, в некоторых случаях у него на переписку и звонки уходило бы до 50% рабочего времени. А еще хороший менеджер — это немножко Customer Care. Этакая мамка для Клиента (и для Команды тоже), которая всех успокоит и решит любой вопрос полюбовно, хорошо разобравшись в ситуации.
Такой менеджер может не знать и не должен знать тонкостей, он не может точно или даже примерно определить масштабы доработок и их влияние на сроки и бюджет. Для этого есть технический лидер проекта, в обязанности которого входит быстрая и качественная экспертная оценка, чтобы при возникновении у Клиента Гениальной Идеи быстро и точно оценить как это помешает достижению поставленных целей.
Конечно, менеджер должен уметь отсеивать откровенный треш, но любые манипуляции с пулом задач должны исходить от технического лидера, а не от менеджера. Либо как минимум верифицироваться у него, т.к. в любой разработке всегда куча тонкостей.
Такой менеджер может не знать и не должен знать тонкостей, он не может точно или даже примерно определить масштабы доработок и их влияние на сроки и бюджет. Для этого есть технический лидер проекта, в обязанности которого входит быстрая и качественная экспертная оценка, чтобы при возникновении у Клиента Гениальной Идеи быстро и точно оценить как это помешает достижению поставленных целей.
Конечно, менеджер должен уметь отсеивать откровенный треш, но любые манипуляции с пулом задач должны исходить от технического лидера, а не от менеджера. Либо как минимум верифицироваться у него, т.к. в любой разработке всегда куча тонкостей.
Еесть очень интересный курс Model Thinking
Там в том числе есть и модели человеческого поведения. Так вот, суть такая что человеческое поведение можно разделить на три основных модели:
— рациональная (выгода, логика, объективность) — обычно занимает больше времени на принятие решения
— поведенческая (эмоции, интуиция)
— основанная на правилах
Валера в начале истории, когда взял на себя невыполнимые обязательства по проекту действовал в рамках поведенческой модели поведения, и частично в рамках правил («нельзя говорит нет руководству»).
А как мы выяснили позже единственное верное решение можно принять только используя рациональную модель поведения, не смотря на то что она требует от нас больше времени и ментальных усилий здесь и сейчас, это единственная модель которая поможет в итоге остаться в выигрыше.
Там в том числе есть и модели человеческого поведения. Так вот, суть такая что человеческое поведение можно разделить на три основных модели:
— рациональная (выгода, логика, объективность) — обычно занимает больше времени на принятие решения
— поведенческая (эмоции, интуиция)
— основанная на правилах
Валера в начале истории, когда взял на себя невыполнимые обязательства по проекту действовал в рамках поведенческой модели поведения, и частично в рамках правил («нельзя говорит нет руководству»).
А как мы выяснили позже единственное верное решение можно принять только используя рациональную модель поведения, не смотря на то что она требует от нас больше времени и ментальных усилий здесь и сейчас, это единственная модель которая поможет в итоге остаться в выигрыше.
Читая статью, сразу вспомнилась книга Роберта Мартина, интересная интерпретация, спасибо :)
Sign up to leave a comment.
Умей говорить «нет» и умей говорить «да»