Как стать автором
Обновить

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

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

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

Как бы очевидные вещи, но вспомнить о них еще раз несомненно полезно.
Не забудьте про продолжение.
У Валеры и его команды бурная жизнь, поэтому продолжение будет :)
Правильные вещи говорите. Так и надо учить. Вот только не забыть добавить, что мир не черно-белый, а «да» или «нет» Валеры зависят не только от профессионализма и мудрого руководства проектами. Иначе есть ненулевой шанс, что крутой профессионал Валера и его команда останутся образно говоря без работы, пару раз круто сказав профессиональное «нет», на что проект образно уйдет индусам и прочим китайцам, о «йес-мэнстве» которых ходят легенды. Т.е. профессиональный ответ — это хорошо, но иногда заказчику надо сказать «да» (или «нет») по политическим, бюджетным и прочим мотивам.
Да, согласен с вами. В рассказе описывается что-то вроде идеала, который нужно держать в уме, принимая какие-то решения. Но он не всегда достижим — жизнь сложная штука. Еще следует сказать, что советы применимы и к процессам внутри компании. Как в истории с роутером. И чем больше людей так себя будут вести, тем эффективнее будет работа.
НЛО прилетело и опубликовало эту надпись здесь
О том и разговор: «Так проблему не решить» часто проигрывает «Не боись, чувак, сделаем в лучшем виде!». Для пессимистичного или оптимистичного прогноза одного профессионализма мало. Есть еще факторы.
Да, всё верно… Но вот вспоминается мне случай из моего опыта. Начальник на предварительных переговорах с клиентами вот именно так «непрофессионально» сказал «да» в ответ на вопрос клиента, сможем ли мы сделать требуемую работу. Сказал от балды, не посоветовавшись с командой, и в результате… мы получили заказ. Да, обязательства были явно авантюрными; да, в результате были авралы, и код с костылями, и куча недоделок… Да, всё так. Только вот если бы он тогда поступил профессионально и сказал «нет», заказа у нас вообще бы не было.
НЛО прилетело и опубликовало эту надпись здесь
Это очень и очень зависит от обстоятельств. Команда, в которой я тогда работал, занималась построением виртуальных миров. Заказы большие, но их очень немного, и пропуск заказа мог бы обернуться потерей команды.
Именно так и должно быть. Еще можно добавить про периодический контроль выполнения задачи. Пока ты подчиненный, тебя раздражают такие начальники: ставят конкретную задачу, заставляют четко отвечать на вопросы, постоянно до срока спрашивают, ну когда же, когда? И даже из отпуска им неимется — звонят, спрашивают. А уже когда сам становишься руководителем, то понимаешь, что только так можно достичь гарантированного результата.
Но что происходит, если так не делать? А просто: директор сказал начальнику отдела, начальник отдела — начальнику сектора, тот подчиненным, а те забыли. И все дальше спят на работе, меняя 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% процентах готовности у вас должен быт работающий прототип системы, который можно «пощупать» и даже отдать на тестирование. Как привило, начальство, не старые пердуны, которые кроме как про водопадную модель ничего не знают. Просто надо деликатно напомнить (даже если об этом и не спрашивают), то что «это» даже если и работает, то основная работа еще впереди, которая подразумевает не просто навешивание «рюшечек».

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

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