Senior PM в EPAM
  • Хороший-плохой менеджер: небожители, тираны, нетехнари и другие типажи

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

    Поддержали: Tetiana Lavrina, Ваня
  • Хороший-плохой менеджер: небожители, тираны, нетехнари и другие типажи

    Хороший, плохой, злой :) Мне кажется, самое большое зло менеджера — пускать процессы на самотек. Это не означает, что надо сваливаться в микроменеджмент или жарко дышать за спиной каждого разработчика.
    Точнее, это самое большое зло, если исключить чистую клинику типа тирании.
    По поводу технарь/не технарь. Вопрос стоит иначе. Технические знания — всегда плюс, даже в работе менеджера, но достаточно ли он хорош, чтобы просто не лезть не в свое дело? Не советовать, к примеру, что и как кодить. Если да, то лучше, чтобы он был технарем.
    Впрочем, важно понимать, что менеджер — это не повышение для технаря. Это просто ВООБЩЕ ДРУГОЙ вид деятельности. Любой менеджер, даже чемпион мира по менеджменту, ничего не производит сам, но отвечает за работу других людей. Отсюда следует очень простой рецепт: надо создать условия для команды, не мешать ей создавать продукт, но по дороге решать проблемы, которые возникают и с которым команда не справится сама.
    И держать руку на пульсе, естественно. Чтоб потом не было митинга с топ-менеджментом на тему: «Как же так?! Все было так хорошо, а потом стало так плохо!»

  • Опоздания, как с ними бороться и стоит ли это делать?

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

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

    И второе. Если у менеджера есть что-то в голове, он никогда не будет считать эти часы. И члены команды могут работать из дому, из другой страны, откуда угодно. Но. Если есть ивент, и есть зависимые от него вещи, а команда состоит не из одного человека, пропадание разработчика (физически из офиса, из скайпа, из слека — не суть) на пару часов создает проблемы проекту. Его кто-то должен ждать. А теперь представьте, что так сделал не один из 15 членов команды, а 2, 5 или 7. Все хорошо, потому что оно так или иначе компенсируется? Или потому, что когда они появятся в онлайне, всё закодят с мегаперфомансом?

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

  • Опоздания, как с ними бороться и стоит ли это делать?

    Давайте не мешать 3 разных проблем в одну. При вменяемом клиенте и менеджменте сказки не помогут. То, что заказчик остался недоволен — привет менеджменту: если даже недовольство заказчика не имеет разумной основы, сам факт его, недовольства, существования — объективная реальность. Не вижу ни противоречия, ни связи с оценками.

  • Опоздания, как с ними бороться и стоит ли это делать?

    Конечно, нет. Цель — не это. Но я пытаюсь понять, исходя из чего вы оцениваете перфоманс? В чем он измеряется?

  • Опоздания, как с ними бороться и стоит ли это делать?

    И так же написано в контракте? :)

  • Опоздания, как с ними бороться и стоит ли это делать?

    Правильно оценивать задачи? Есть только один способ всегда попадать в свои оценки — завышать их. Вопрос не в пальцем в небо, а том, что при решении сложной задачи всегда есть риск.

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

    Но Вы, как всегда, снова все знаете сами — веб, круд и валидация...

  • Опоздания, как с ними бороться и стоит ли это делать?

    А по существу? Не ныряя в то, что я могу или не могу представить?

  • Опоздания, как с ними бороться и стоит ли это делать?

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

    Больше чем одна команда на Продукт — и у вас уже коммуникации простыми не будут. Не надо примитивизирвоать, не все проекты в одного разработчика. И нет, не разработчик решает, где ему принимать участие — это вытекает из логики проекта и структуры команды.

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

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

  • Опоздания, как с ними бороться и стоит ли это делать?

    А до 15-00 двое покурят бамбук? Сложность = бардак? Кто говорил, что речь о синьорах? Но даже если так, то что? Обиделся, что не 8К и два часа играл на балалайке? Профессионально.

  • Опоздания, как с ними бороться и стоит ли это делать?

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

    2. Наверное, Вы чего-то не понимаете. Я объясню. Например, у Вас 4 айос разработчика, которые с Продакт овнеровм должны обсудить бизнес ценность, распилить ее на задачи и спланировать имплементацию. 2 из 4х спят до 14-00. Так понятнее?

    3. Почему не станет? У одного разработчика может быть в 2 раза больше зарплата по причине его высокой производительности.

    И не надо о лайках котиков, это подмена понятий. Я нигде не говорил «сидеть» в офисе, я говорил «работать» то количество времени, за которое вам платят. Да, если проект позволяет, можете работать с 8 до 4, или с 12-00 до вечера, но в любом случае вам платят за время.

  • Опоздания, как с ними бороться и стоит ли это делать?

    Штраф просто легитимизирует пропуски митингов и дает обратный эффект. Что будет если ВСЕ члены команды решат, что можно не приходить? Часть разработчиков, очевидно, мало интересует, откуда берутся деньги на их зарплату. Очень дальновидная и цельная позиция.

    Поддержал: Vadim Kopanev
  • Опоздания, как с ними бороться и стоит ли это делать?

    Логика сторонников прихожу, когда хочу, просто прекрасна. Могу, мол в 14-00 и все сделать до 18-00 и смело свалить, потому что у меня перфоманс.

    Давайте попробуем по полкам.
    1. Вам платят за время, буквально. Если вы хороший работник, за это время вам платят больше, чем тем, кто хороший в меньшей степени.
    2. Прийти, к примеру, на два часа позже, это забрать эти два часа. Просто забрать деньги, ничего не дав взамен. Ненуачьо?
    3. Чей-то коммент, а если я буду сидеть 8 часов и за это время сделаю в два раза больше, мне заплатят в два раза больше? Я не знаю. Но если не устраивает зарплата — обсуждайте с менеджментом, а не просто забирайте у него свое время.
    4. Никто не говорит поставить таймер на 9-00 или 10-00 и умножать фактическое время на рейт. Но приход в минус час-полтора — это просто неуважение к коллегам, членам той же команды, с этической точки зрения и воровство с финансовой.

    Не вижу, где тут можно что-то трактовать по-другому.

  • World of tasks, или Куда разработчикам прикладывать Product thinking

    Мир не идеален. Поэтому я добавил первый абзац в Выводах

  • World of tasks, или Куда разработчикам прикладывать Product thinking

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

    Поддержал: Denys Kostin
  • World of tasks, или Куда разработчикам прикладывать Product thinking

    Это скилл, но не в сфере продукта. Скилл понимать, для чего ты делаешь то, что ты делаешь. Никто не требует погружаться в глубины или думать вместо Head of Product. Я не знаю, что такое, как вы выразились, небольшое понимание, но я говорю об общей логике и понимании контекста своей работы.

  • World of tasks, или Куда разработчикам прикладывать Product thinking

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

  • World of tasks, или Куда разработчикам прикладывать Product thinking

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

    Поддержал: Максим Ковтун
  • World of tasks, или Куда разработчикам прикладывать Product thinking

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

  • World of tasks, или Куда разработчикам прикладывать Product thinking

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

    Поддержал: Максим Ковтун
← Сtrl 123 Ctrl →