Пьеса «Технический долг»

    Пьеса «Технический долг» в 9 частях. Ставится и показывается впервые.


    Часть 0: В пустой комнате стоят Разработчик (Р) и Менеджер (М).

    М: Я собрал нас тут, чтобы рассказать пренепреятнейшее известие: система КРОТОПОН, которая работает на продакшане заглючила и мы потеряли кучу денег. Кроме того нет никого, кто знает как она работает. Поэтому (с придыханием) наш СЕО дал мне священную миссию — написать новую систему. Как ты думаешь, за два месяца справишься?

    Р: А что делать-то нужно?

    М: Да там немного, всего лишь пару десятков систем связать и рюшечки навесить.

    Р: Эй, да это же на год работы! И вообще требования будут?

    М: (В телефон) Да, конечно, за пол года справимся. (Разработчику) Ну ты тут пока начинай, а я тебе требования потом донесу.

    Менеджер уходит.

    Р: Но тут же…

    Разработчик тяжело вздыхает, затаскивает в комнату инструменты и начинает что-то сооружать.


    Часть 1: Через 2 месяца. В комнате сидит Разработчик и что-то строгает. Забегает радостный Менеджер и протягивает Разработчику большую папку.

    М: Знаешь что я принес? Это требования к системе составленные нашим главным писателем. А еще нашим проектом заинтересовался СЕО, так что мы релизимся на месяц раньше!

    Р: (ошарашенно) Но ведь у нас всё рассчитано на пол года!

    М: Не волнуйся, вот посмотри я подробные требования принёс, всё получится!

    Разработчик смотрит требования.

    Р: Но ведь это булшит, мы вообще об этих требованиях не слышали!

    М: А, это? Это попросил сам СЕО, так что нужно обязательно сделать.

    Р: Но я же не успею!

    М: Не волнуйся, я что-нибудь придумаю.

    Менеджер убегает. Разработчик начинает разбирать собранное в центре комнаты.

    Часть 2: Через месяц, Разработчик собирает что-то совершенно не похожее на сооружение из предыдущей сцены. Входит Менеджер.

    М: Радуйся, я привёл нам помощь!

    Р: О, кто-то ещё будет разрабатывать этот продукт? Тогда мы справимся!

    М: Не совсем. Знакомься, это наш Скрам-мастер!

    Входит Скрам-мастер (С).

    С: Здравствуйте дети! Всмысле приятно познакомится!

    М: Он поможет тебе лучше распределять время между задачами повысит производительность нашей команды.

    Р: Но я же один в команде…

    С: Не волнуйся, я только что прочитал об особом виде СКРАМ, который как раз подходит для команд из 3-х человек.

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

    Часть 3: Месяц до релиза. Скрам мастер сидит в центре комнаты в позе йога, Разработчик пытается соединить всё в углу комнаты. Входит Менеджер.

    М: О, я вижу у вас всё готово? Хорошо!

    Р: Оно неидеально, но к началу тестирования я успею закончить.

    М: А, ты про это… У нас не будет тестирования.

    Р: Что?

    М: Я поговорил с ВИПами и они хотят видеть всё за 2 недели, как мы покажем всё СЕО. Так что тестирование отменяется.

    Р: Но ведь у меня нет времени укрепить всё к этому показу!

    М: Не проблема, подопри костылями и прибей гвоздями.

    Р: Оно не будет работать и мне стыдно будет показывать такой код!

    М: Не волнуйся, мы всё исправим после релиза.

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

    Часть 4: Неделя до релиза. В окне мелькает молния, в углу стоит противотанковый ёж из костылей. Рядом спит Разработчик. Вбегает Менеджер и будит Разработчика.

    М: Надо всё переделать!

    Р: Как? Что? Оно же работает!

    М: Наш проект посмотрели випы и вот список доделок которые нужно сделать до показа СЕО.

    Менеджер выходит из комнаты и ввозит тележку заполненную бумагой.

    Р: Но… как? (Смотрит на первую попавшуюся бумажку из кучи) Это же соврешенно не так, как было написано в требованиях!

    М: Забудь про требования, надо сделать так.

    Р: Но ведь Скрам-мастер говорит, что мы не будем принимать новые требования!

    С: Ты знаешь, новые требования принимать нельзя, но если очень хочется, то можно переключиться на особый вариант аджаил для котов и там это допустимо. Кстати меня уже позвали помочь соседнему проекту, я пойду.

    Скрам-мастер уходит.

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

    Менеджер демонстративно садится напротив Разработчика и начинает на него смотреть.

    Р: Ладно, я попробую что-нибудь сделать, но после релиза нужно будет всё исправить!

    М: Да, конечно, у тебя будет время на это после релиза.

    Разработчик начинает разбирать бумаги в тележке, Менеджер на него смотрит.

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

    М: (Оглядываясь вокруг) Хорошо поработали. (Тормошит разработчика) Ты знаешь, наш проект хорошо оценили. Так и сказали, что я мастер управлением персоналом, что смог вытащить этот проект за такой малый срок. Так что меня повысили. Знакомься, это твой новый менеджер!

    Входит Менеджер 2 (М2), Менеджер раскланивается с ним и выходит.

    М2: (смотрит на полу-спящего Разработчика) Привет! Надеюсь ты полон сил и решимости работать на благо нашей компании?

    Р: (с трудом садясь) Да, надо подчистить технический долг после релиза… И Менеджер обещал мне премию…

    М2: Странно, мне он забыл об этом сказать. Я спрошу его. А пока, раз ты готов решимостью, мне нужна помощь с другим проектом.

    Менеджер 2 выходит и вкатывает телегу с гавном.

    Р: Это же куча говна!

    М2: Нет, это очень важный проект, который сделал наш Гуру. Тебе нужно всего лишь исправить пару маленьких недоделок внутри, тогда и поговорим о премии кстати.

    Менеджер 2 уходит.

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

    М2: Ну вот, отлично выглядит, а ты говорил что куча говна.

    Р: Так можно мне премию?

    М2: Да, да, конечно. Я обо всём договорился. Только мы немного опоздали и поэтому прийдётся ждать окончания следующего отчётного периода через 6 месяцев. Кстати решено выпустить вторую версию этого замечательного продукта (оглядывает покачивающегося противотанкового ежа в углу комнаты).

    Р: (отряхиваясь от говна) Хорошо, наконец-то я смогу починить эти костыли!

    М2: Нет, на это нет времени. У нас есть куча новых требований.

    Р: Но приложение же нестабильно! Я не смогу добавлять новую функциональность, пока не исправлю старую!

    М2: Не бойся, я попрошу о помощи, начинай делать.

    Часть 7: Те же лица, Разработчик пытается что-то делать.

    М2: Возрадуйся, я договорился о помощи!

    Р: Надеюсь не Скрам-мастера?

    М2: Нет, я привёл настоящего профи своего дела! Знакомься, Гуру. Ты уже видел его проект (кивает на телегу с гавном).

    Входит Гуру(Г).

    М2: Гуру будет руководить доработками. Вопросы?

    Р: Но я же лучше знаю проект…

    М2: Да, покажи проект Гуру.

    Разработчик начинает показывать проект.

    Р: А тут у нас куча костылей, их планировали исправить до релиза.

    Г: (покачивая головой в разные стороны) Да, понимаю.

    М2: Ну как, разобрались, успеете?

    Г: Конечно, сделаем всё в лучшем виде. Начнём с самой важной части — платформы. Всё просто необъодимо переделать согласно последним трендам.

    Р: Но…

    М2: (хлопая в ладоши) ну вот и разобрались!

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

    Г: Ну вот, я даже перевыполнил план, заодно добавил интеграцию с прошлой системой. Кстати забыл сказать, я ещё работаю на 10 других проектах и моё время для этого проекта вышло, но я буду заходить и смотреть что ты сделал. Дальше уже тривиально. Пока!

    Гуру выходит из комнаты.

    Р: Всё, меня всё достало, я увольняюсь!

    М2: Премия. Сразу после релиза.

    Р: Да мне уже больше предлагают!

    М2: Тогда ещё повышение зарплаты, тоже после релиза. И вообще ты профессионал или где? Уходить сейчас непрофессионально!

    Р: Ок. (начинает собирать костыли с пола)

    Часть 9, заключительная: В центре комнаты стоит телега с гавном и скульптурой из костылей, сидит Разработчик. Входят Менеджер 2 и Гуру.

    М2: Какие мы молодцы, что сделали эту систему! Особенно важна самоотверженность с которой ты (обращается к Гуру) в условиях жёсткой нехватки времени идеально встроил новую платформу! Обязательно выдам тебе хорошую премию.

    Р: Надеюсь вы не забыли про меня?

    М2: Нет, конечно нет! Только у меня для тебя новость — я вместе с Гуру перевожусь в другой отдел, так что тобой займётся уже Менеджер 3. А вот кстати и он!

    Менеджер 2 и Гуру уходят, входит Менеджер 3(М3).

    Р: Давай поговорим о моей премии и повышении зарплаты, о которых я договорился с Менеджером 2!

    М3: Подожди, подожди, я слышал об этом, но мне кажется что там повышение слишком большое. Тем более основную работу сделал Гуру. Давай поговорим об этом через 6 месяцев, когда я присмотрюсь к тебе. Сейчас мне всё равно не выделили бюджет на увеличение зарплатного фонда.

    Р: Да идите вы… (Разработчик пишет заявление ПСЖ и увольняется, уходит со сцены)

    Менеджер 3 пишет записку «Так как Разработчик был недостаточно лояльным и уволился прошу выделить мне команду для поддержки этого приложения а пока мы замораживаем все работы по нему».

    Через пол года всё рассыпается и компания теряет много денег. Обвиняют во всём уже ушедшего из компании Разработчика и решают сделать новую систему, так как никто не понимает как работает старая.

    КОНЕЦ
    При написании этого текста не пострадал ни один костыль.
    Все совпадения с реальными людьми и событиями считать злонамеренными.
    Метки:
    Поделиться публикацией
    Реклама помогает поддерживать и развивать наши сервисы

    Подробнее
    Реклама
    Комментарии 193
    • +20

      Спасибо, давно так не рыдал

      • –52
        Как-то вы излишне демонизируете менеджеров, будто они совсем не заинтересованы в успехе проекта.

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

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

          — Аааа, у нас на проекте все очень плохо, почему ты не предупредил что так может быть?
          — Но я же говорил что будет плохо если не сделать то и то…
          — Да, но ты не говорил что будет ОЧЕНЬ плохо. Ты не старался до меня донести! Ты во всем виноват!
          • –20
            Ну надо понимать, с кем ты разговариваешь. Что для тебя очевидно, для него может быть нет. Он небось и считать умеет только до десяти, и математику последний раз видел в 9ом классе.
            • +21
              Он небось и считать умеет только до десяти, и математику последний раз видел в 9ом классе.
              Тогда почему он считает что он может решать, что нужно делать, а не я? И почему он вообще принимает какие-либо решения, если я должен до него «доносить» какие от них могут быть последствия?
              • –25
                Потому что он умеет и не боится взаимодействовать с неидеальным внешним миром и ориентироваться на результат.

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

                  Ты наверное М3 из рассказа.

                  • +7
                    Справедливости ради стоит отметить, что бывают (редко) менеджеры, вышедшие из разработчиков: это типа как мульти-класс в AD&D: качаешься до 10 lvl «Разработчиком», а потом получаешь новый класс и снова до 10 с нуля: долго, сложно, зато в конце получается не специалист, а конфетка. Времени на это правда уходит вагон и маленькая тележка.
                    • +5
                      Очень много историй, как разработчики уходят в менеджеры, считая это развитием, а в итоге оказываются жестко ограничены окружающими условиями и перестают развиваться. За это время выходит тысяча новых фреймворков, меняются тренды и ценность этого человека как программиста безнадежно падает (причем наверняка не объективно, а лишь в глазах М1-М3).
                      • 0
                        Все самые «жесткие ограничения» у человека в голове.
                        • +1
                          Даже если разработчик «устаревает» — он всё равно лучший менеджер потому что он более в теме, чем просто чистый манагер. Тупо потому, что он понимает, что вот взять вот этот кусок говна с костылями и «прикрутить к нему фигулинку» — это не «5 минут… ну максимум час, что тебе сложно что ли? Мы же так уже делали в проекте ААА, а здесь — точно так же». Он знает, что «точно так же» — нифига не так же, знает, что из процесса разработки — нельзя выкинуть «неважные детали» типа тестирования. И ещё много разных «он знает, что ...».
                          • +1
                            так они уходят за разитием себя в смысле карьеры или личных целей, а не в смысле развиваться как «еще более лучший»™ программист.
                            поддерживать ценность себя как программиста после перехода в менеджмент это нерациональное использование ресурсов.

                            • 0
                              Вы не совсем верно меня поняли. Я говорил именно о том, что разработчик уходит в менеджеры ради карьерного роста и личных целей, пологая что завис в пространстве, работая разработчиком. И в итоге попадает в комнату со стеклянным потолком: его вроде как и не видно, но он очень сильно ощущается. После этого он понимает, что пути развития в роли разработчика у него были, а в роли менеджера он действительно не может двигаться дальше. Я не утверждаю, что это верно для всех ситуаций, а всего лишь говорю, что такое происходит и даже не раз было описано на хабре/гиктаймс.
                              • 0
                                ну это фундаментальное изменение, честно говоря я не думаю, что такого уровня непонимание развития карьеры часто встречается.
                                неправильная оценка того что хочешь это да (хочу руководить, а на самом деле нет), но вот что путь к разраб 80lvl -это через менеджера, такое думаю редко.
                              • 0
                                поддерживать ценность себя как программиста после перехода в менеджмент это нерациональное использование ресурсов.

                                Как показывает хотя бы этот топик, менеджер с актуальными навыками программирования и всего вокруг него более востребован программистами как начальник (product owner в SCRUM). Субъективно, у такого менеджера доля успешных проектов и удачных спринтов будет выше.
                                • 0
                                  более востребован программистами как начальник


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

                                  (SCRUM product owner — это не менеджер все же)

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

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

                                    (Как не менеджер, если принимает бизнес-решения по распределению ограниченных ресурсов?)

                                    Тут зависит от того, что считать разработкой. Например, вот начал я работать один над проектом (веб-приложение в интранет), начал зарываться со временем — с одной стороны обычный поток задач, связанных с развитием бизнеса, с изменением законодательства и т. п., с другой — хотелки стейкхолдеров, которые наконец-то получили человека, который успешно их реализует. Анализ ситуации показал, что много времени уходит на рутинные задачи по фронтенду, взяли мне в помощь фронтендера. Я ставлю ему чёткие задачи с указанием необходимого мне пути решения, вплоть до ссылок на библиотеки, которые надо использовать, он их выполняет. Можно ли сказать, что я перестал заниматься разработкой фронтенда? Код писать перестал почти, а вот разработкой, по-моему, не перестал заниматься. С другой стороны, можно ли сказать, что я стал менеджером? Как по мне, то стал. Я делегирую ему решение своих подзадач, ставлю приоритеты, контролирую прогресс и качество, отвечаю по сути за результат его работы. Чем не менеджер?
                            • +5
                              Это называется Dual Class а мультикласс это когда развивается сразу во всех направлениях.
                          • +13
                            Потому что он умеет и не боится взаимодействовать с неидеальным внешним миром и ориентироваться на результат.

                            Это такая идеальная отмазка, чтобы скрыть некомпетентность руководства?
                            • –10
                              Если у тебя есть все необходимые компетенции, то почему ты сам не пошёл в руководство? Программистам не нравится работать менеджерами, применять необходимые для этого навыки. Вот к ним и приходит менеджер со стороны, чтобы заполнить вакансию. Может он вообще программы не выпускал, а дороги катал или катком заведовал. Он имеет все необходимые знания для менеджера, но не имеет опыта в конкретной предметной области.
                              • +2
                                Если у тебя есть все необходимые компетенции, то почему ты сам не пошёл в руководство?

                                Не нравится.
                                • –6
                                  Ну вот. Значит придётся терпеть того, кто пришёл на эту должность.
                                • +2
                                  Ну пусть катает дороги дальше.
                                  Или в нашей удивительной стране кухарки могут управлять не только государством, но и высокотехнологичным производственным процессом?

                                  PS: У меня нет необходимых компетенций, чтобы быть в руководстве, у меня есть компетенция в области разработки ПО. Потому и не иду.
                                  • –5
                                    А что в вашей удивительной стране программисты после выпуска из вуза знают сразу 100500 языков и фреймворков, каждую предметную область, от вебсайтов до микроконтроллеров, от игрушек до геораспределённых систем? Могут использовать любую известную базу данных или изготовить свою?

                                    Нет. Так зачем же требовать от менеджеров всезнания? Помогайте ему по мере ваших сил, у вас один проект и одна цель!
                                    • +3
                                      Как-то Вы лихо с больной головы на здоровую. Задело, что ли? Не хотел, честно.

                                      Я же не требую всезнания от менеджеров, я требую компетенции в заявленной области. Думаете, я не видел программистов, которые заявляли больше, чем умели?
                                      • +2
                                        Вы сравниваете менеджера, который пришел с укладки дорог, и программиста, которіе не знает все фреймворки? Это, по-вашему, хорошая параллель?
                                        • –5
                                          Ну а что, сейчас менеджеры прям при выходе из менеджерских ВУЗов в курсе как работают кодеры в IT? Они же не знают, где ещё будут применяться их знания, основной их навык — это «программирование» людей. А на какую задачу их нужно будет программировать, наперёд не известно.

                                          Точно так же как выпускнику прогерского ВУЗа не известно, какой ему придётся JS движок использовать в работе. Научится по дороге.
                                          • +11
                                            Они же не знают, где ещё будут применяться их знания, основной их навык — это «программирование» людей. А на какую задачу их нужно будет программировать, наперёд не известно.

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


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

                                            • +3
                                              У менеджеров, на минутку, тоже есть специализации типа «управление машиностроительным производством», где как раз таки понимание особенностей работы и организации работ в данной отрасли очень важно. Без этого понимания и будет получаться что «Возьмем 9 беременных женщин и родим ребенка за месяц. Ну а чо, я ж не биолог.»
                                              • 0
                                                Кстати, да. Именно на него я учился второй раз.
                                          • 0
                                            Проект, может, и один, а вот цели не совсем одни. На многих проектах менеджерам важнее сроки и большой список фич, чем пустой список багов.
                                            • +2
                                              В пьесе описан менеджер, который, не являясь компетентным, не слушает того, кто является компетентным. В этом-то и проблема.
                                              От менеджера не требуется всезнание — от него требуется коммуникация не только с начальством, но и с подчинёнными. Только в этом случае это один проект и одна цель. А то, что описано в пьесе, больше похоже на «я начальник, ты дурак». Это не один проект и одна цель, это — спущенная сверху разнарядка, от реальности очень сильно оторванная.
                                              Ты можешь не знать всего — и это нормально — но если проект для тебя значит больше, чем собственные амбиции, ты будешь слушать своих подчинённых и опираться на них, а не приказы начальства. Если же впереди амбиции, то получается ровно то, что описано в пьесе. И цена такому менеджеру — нуль. Вне зависимости от его знаний и опыта. Не надо искать оправданий очевидной некомпетентности.
                                          • +1
                                            > Он имеет все необходимые знания для менеджера, но не имеет опыта в конкретной предметной области.

                                            Ну вот потому такого менеджера и не следовало бы брать в ИТ.
                                            • +4
                                              Программистам не нравится работать менеджерами, применять необходимые для этого навыки.

                                              Полагаю у вас однобокая статистика. Все менеджеры кроме одного с которыми я работал, будучи разработчиком, были либо бывшими либо действовавшими программистами. И проект знали или на уровне разработчика или на уровне администратора. И это опыт по трём компаниям и полудюжине менеджеров.
                                              • +5
                                                Работающие в таких компаниях обычно не пишут подобные статьи.

                                                Речь идёт об «эффективных манагерах», которые, по сути применяют один и тот же алгоритм:
                                                1. Корову меньше кормить и чаще доить.
                                                2. Получить бонус на «эффективность».
                                                3. Вовремя свалить (в идеале — на повышение).

                                                Для этого, в сущности, знаний не нужно — достаточно звериного чутья. Потому что пунк #3 — ключевой.
                                                • –1
                                                  +1 немного поработал в нескольких стартапах из США (удаленно, но все же), возможно не все, но часть практикует «горизонтальную» структуру управления, когда тебе звонит по скайпу инвестор-менеджер проекта и он может не имеет обширной практики программирования на языке X, но прекрасно разбирается в терминологии и software development в целом и говорить с ним можно на техническом сленге, без всяких скидок — «ну он же не понимает». И как правило проекты под руководством таких менеджеров заканчиваются успешно, чего не скажешь о тех «менеджерах» которые лезут «руководить» в той области в которой не разбираются.
                                        • +1
                                          С другой стороны, эта система уже может приносить деньги, которые полностью окупят дальнейшие затраты.
                                          • +1
                                            а потом момент упущен, рынок перенасыщен, затраты на маркетинг увеличиваются на порядок (а то и на несколько). И в конечном итоге выходит, что нафиг никому не нужен ваш чистовылезанный проект. Как бы самому не было противно, но таковы реалии
                                        • +28
                                          Они не заинтересованы в том, чтобы проект не провалился.

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

                                          Такое состояние приводит к тому, что возникает конфликт интересов и им субъективно выгодно принимать рисковые решения.

                                          • +17
                                            >Как-то вы излишне демонизируете менеджеров, будто они совсем не заинтересованы в успехе проекта.

                                            Неа. На самом деле все еще хуже. Вот совершенно реальный разговор из жизни:

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

                                            Проходит три месяца. Релиза нет, и непонятно когда будет.

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

                                            P.S. Пока писал, появился комментарий выше. И я с ним согласен — конфликт интересов что-то слишком типичен.
                                            • +86

                                              Притча "Менеджер и программист"


                                              Человек, летящий на воздушном шаре, обнаружил, что потерялся. Он спустился немного ниже и заметил на земле женщину. Спустившись ещё чуть ниже, он обратился к ней:
                                              — Простите, не могли бы вы помочь? Я договорился с другом встретиться час назад, но не знаю, где сейчас нахожусь.
                                              — Вы находитесь на воздушном шаре в 30 футах от поверхности Земли, между 40 и 41 градусом северной широты и между 59 и 60 градусом западной долготы ответила женщина.
                                              — Вы, должно быть, программист?
                                              — Да, а как вы догадались?
                                              — Вы мне дали абсолютно точный ответ, но я совершено не представляю, что делать с этой информацией, и я всё ещё потерян. Откровенно
                                              говоря, вы мне совершенно ничем не помогли.
                                              — А вы, наверное, менеджер?
                                              — Да. А вы как догадались?
                                              — Вы не знаете, где находитесь и куда направляетесь. Поднялись вы туда, благодаря воздуху. Вы дали обещание, которое не представляете, как выполнять, и ожидаете, что люди, которые находятся ниже вас, решат ваши проблемы. И, наконец, сейчас вы в том же самом положении, в котором находились до встречи со мной, но почему-то теперь в этом оказалась виновата я.


                                              Просто почему-то вспомнилось...

                                              • +12
                                                О боги, спасибо!
                                                Через 20 лет я узнал, что у анекдота есть продолжение ("— А вы, наверное, менеджер?")
                                                • 0
                                                  И это еще повезло посреди Атлантики программиста встретить.
                                                  • +3
                                                    > Поднялись вы туда, благодаря воздуху.

                                                    В английском оргинале «you got where you are thanks to a lot of hot air» — тут идиома, на русский в целом переводится как «вы оказались на своей высоте [(должности)] благодаря тому, что много заговаривали зубы/пудрили мозги», но в переводе на русский игра слов с «горячим воздухом» пропадает :(
                                                    • 0
                                                      Я сначала так же подумал, но ведь есть же идиома «торговать воздухом», с натяжкой конечно, но в общем смысл именно в таком переводе есть.
                                                  • 0
                                                    будто они совсем не заинтересованы в успехе проекта
                                                    • +4
                                                      Обычно менеджерам сообщается что-то вроде: эта фича займёт от 40 до 120 часов. Они докладывают наверх: будет готово через неделю, может 10 дней. И при этом постоянно подгружают мелкие задачки на час-два в день, ежедневные совещания на полчаса по фиче, пару совещаний по будущим задачам по часу. Какие ещё скилы нужны от разработчика, чтобы менеджер 120 разделил на, максимум, 6 часов и получил срок в месяц?
                                                      • –1
                                                        Так-же часто бывает обратное: менеджер закладывает 200 и все-равно не успевают
                                                        • +7
                                                          Бывает, да. Но в чём отличие хорошего менеджера от плохого — хороший считает (и не в глубине души, а публично заявляет), что это его ошибка, что он оценку разработчиков выдал за свое обязательство. Плохой же менеджер заявляет, что разработчики не выполнили свои обязательства, а он не причем, он лишь проинформировал руководство об обязательствах разработчиков, да ещё заложил риски, но разработчики всё равно не выполнили свои обязательства.
                                                          • 0
                                                            Спасибо, прекрасный критерий.
                                                            • 0
                                                              Вообще армейский критерий :) С другой стороны, офицер, командир подразделения — это тоже менеджер.
                                                              • +1
                                                                Это плохой критерий, потому что остальные члены команды не чувствуют никакой ответственности и причастности к результату.
                                                                • +3

                                                                  А то, что они этого результата собственно и достигают — это не считается?

                                                                  • +3
                                                                    Результат достигается совместными усилиями команды: разработчиками, менеджерами, аналитиками, тестировщиками, дизайнерами, проектировщиками, ..., а не только программистами. Это без учета сейлзов, без которых вся эта команда сидела бы и сосала лапу.

                                                                    Брукс и Гласс, например, сходятся в оценке того, что «выпустить продукт» требует примерно в 6 (шесть, Карл!) раз больших трудозатрат, чем «написать код». Поэтому логично, что и ответственность лежит на команде, а не на менеджере.

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

                                                                    Тут комменты посмотришь: разработчики все сплошь на галерах гребут, напрягаются во благо компании, а менеджеры смузи только пьют.
                                                                    • +5
                                                                      Вы скажите, где менеджеры «правильные» и ведут себя так, как Вы описали. И есть ли там открытые вакансии? :)
                                                                      • +2
                                                                        Про совместные усилия впаривают менеджеры когда надо выйти в выходные. А по ФОТу явно видно, что программисты просто налипли на проект и ничего существенного сделать могли в принципе. Как вам 3 ведущих менеджера, 4 рядовых менеджера на команду из 7-9 разработчиков, 2.5 тестеров и 0.5 аналитика?
                                                                        • 0
                                                                          Я думаю, что на эту команду нужно 1 или 2 менеджера-администратора. 4 — много. При условии, что среди 7-9 разработчиков есть тимлид один.
                                                                          • 0
                                                                            только не 4 менеджера, а 7.
                                                                            • 0
                                                                              А там еще 3 ведущих))) По одному на разраба. Не знаю, это странно. Что они делают у вас?
                                                                              • 0
                                                                                Я уволился :-) Насмотрелся на весь этот треш и ушел. Точнее как получилось, после закрытия проекта пошел к руководству разговаривать о ЗП, мне сказали что я охренел вконец и хоть весь наш отдел строем уволится, работать всегда будет кому. Или средняя по городу, или по собственному. На улице очередь стоит. Я перешел на удаленку, ЗП в 3 раза выше геммора в 10 раз меньше.

                                                                                P.S. мне эти менеджеры казались виртуальными. я их не видел. может просто чтобы освоить бюджет проекта.
                                                                    • 0
                                                                      Каждый в команде отвечает за свою часть результата. В частности разработчики за выполнение технических требований и качество кода. За сроки разработчики не отвечают, за соответствие бизнес-требований техническим — тоже.
                                                                  • +1
                                                                    С чего вдруг менеджер должен публично брать на себя косяки программиста, не уложившегося в срок? Если «поеахал» критический путь проекта — это ошибка менеджера. Не уложился в оценку — либо ошибка планирования, либо не соответствие занимаемой должности. Способы ослабления рисков не верной оценки известны. В статье автор явно сгущает краски: программист у него лапочка и делает все во благо компании, а менеджер — некомпетентный тиран, угнетатель. В реальности дефицит хороших кадров в IT и в разработки и в менеджменте.
                                                                    • +4
                                                                      > С чего вдруг менеджер должен публично брать на себя косяки программиста, не уложившегося в срок?

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

                                                                      Программист, конечно, тоже может быть виновен в срыве сроков — если он вместо кода фигачил в танки. Но в большинстве случаев провал сроков — это провал планирования и ошибка менеджера.
                                                                      • +2
                                                                        Ок, если так, то почему вы удивляетесь, что менеджер, имеющий слабое представление о технических деталях, назначает неадекватные сроки, если не хотите брать хотя-бы частично ответственно за оценку задач на себя?
                                                                        Менеджер подключен к космическому знанию, предвидит будущее и так планирует сроки? Если нет, то на основании каких данных производится планирование?

                                                                        Программист может оценить задачу, потому что у него есть опыт реализации аналогичных задач (если мы говорим про профессионала). Я оцениваю типовые задачи с точностью до минут. Не типовых задач в энтерпайзе на самом деле не так много, как принято считать.
                                                                        • +4
                                                                          Потому что если я могу вести и планировать весь проект целиком, то зачем мне менеджер?

                                                                          Точное повторение старых действий (при условии неизменности окружения) — это залог идеального планирования.

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

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

                                                                          Потом менеджер должен решить, насколько важен проект, нужно ли закладывать больший запас ресурсов или провал сроков не критичен, и перезакладываться не нужно. Если менеджеру всё ещё слишком не понятно, сколько времени будет уходить на задачи, он может отловить программиста и вместо программирования посадить его за дизайн. Расписать вместе возможное разложение задачи на подзадачи, найти те, которые уже раньше делались и хорошо предсказываются, изолировать те, что предсказываются плохо — с ними продумать отдельно. Но это уже будет решение менеджера, ещё до начала проекта, потратить время программиста вместо программирования на анализ. Программист сам такого решения принять не может.
                                                                          • 0
                                                                            Для этого нужен не менеджер, а архитектор. Менеджер не знает всего этого: он наймет правильного человека, получит оценки и проанализирует риски. Ничего более точного еще не придумали.

                                                                            Мы говорили, не про оценку всего проекта, а про то что нужно укладываться в оценки по своим задачам. Планировать весь проект разработчика ни один грамотный руководитель не попросит.
                                                                            • 0
                                                                              Э… Извините, что? Менеджер не знает, что такое иерархическое дерево работ? Да, для его построения ему нужен специалист в разработке, к которому он придет с верхнеуровневым деревом (эпики, фичи, стори), а тот уже разобьет на тривиальные оценки.
                                                                              Правда, эта вся фигня с диаграммами Ганта выглядит красиво в ПМБуке, в Прожекте каком-нибудь, а вот в реальном проекте вдруг выясняется, что заказчик хотел не этого, а вот того. Это должно быть не так, а вот этак. Ну и все первоначальные оценки или идут в корзину, или идет торг на уровне «мы сделаем это, но выкинем вот это», или идет раздувание сроков-бюджетов. Там куча всяких интересных вариантов. Опять же будет своя специфика с внутренней разработкой, продуктовой, заказной. Не зря же пытаются всякие итеративные, инкрементальные способы разработки внедрять. Как раз из этих соображений, что самая адекватная оценка, это оценка полученная в процессе работы. Да и чем дольше идет проект, тем лучше предсказание рисков и все такое.
                                                                              • 0
                                                                                А что если повторения нет, если задача отличается от той, что ты решал до этого? Нужна другая архитектура, другие библиотеки, у каждой — непредсказуемые временные затраты на внедрение. Как быть в этом случае? Программист может прикинуть лишь примерно, а затраты времени могут расти как фрактал.

                                                                                Я имел в виду, что разработчик отвечает за свои оценки. Остальное, видимо, все поняли по-своему
                                                                                • +2
                                                                                  Я разработчик, я отвечаю за свои оценки. Приходит ко мне менеджер и говорит: «Сколько?»
                                                                                  Ну я же отвечаю, за свои оценки, поэтому я, прикинув, что задача на 2 часа, но придет менеджер Петя и попросит подсказать как сделано А, потом забежит аналитик Света и попросит посмотреть нормальное ли требование Б, потом может быть недоступен тестовый стенд, дам оценку в 10 часов.
                                                                                  Что скажет на это менеджер?
                                                                                  • –1
                                                                                    Это все хрень. Организуйте свою работу так, чтобы тестовый стенд работал и Васи и Светы не забегали и делайте за 3 часа.
                                                                                    • +9
                                                                                      Э… Я как разработчик должен организовать свою работу так, чтобы меня не дергали менеджеры, аналитики, тестировщики, заказчики. Точно? За это отвечает не менеджер? Т.е. я должен послать вас когда вы придете ко мне за оценкой? Так? Если да, то зачем вы пришли?
                                                                                      Я как разработчик должен договориться с отделом эксплуатации чтобы мне развернули нужный тестовый стенд или это ваша работа как менеджера?
                                                                                      Чтобы не было недоразумений, я уже лет 7 как менеджер, а первые подчиненные у меня появились лет 15 назад.
                                                                                      Мы живем в мире с высокой неопределенностью. Разработчик дал вам оценку в 16 часов. А потом у него подскочила температура и он ушел в больницу. Вы его не отпустите? Или это он виноват, что не решил задачу за 16 часов?
                                                                                      • 0
                                                                                        Я говорю только про риск «низкая производительность труда». Падения метеоритов, температура и прочее случаются. Все это понимают.
                                                                                        И я про 3 часа которые в ворк-логах, а не календарные.
                                                                                        • 0
                                                                                          А теперь как только на задачи которые я оцениваю в два часа, я буду ставить три, то быстрее трех я ее делать не буду. Ведь так? А потом я буду на эту задачу (помня что она занимает три часа) говорить четыре. Да? И вас это будет устраивать?
                                                                                        • 0
                                                                                          Если разработчику мешают и поэтому он не укладываются, нужно сказать, так и так я по факту не работаю, а болтаю с аналитиками и отделом внедрения. Светку надо уволить, потому что дура она, а не аналитик. С заказчиками должны общаться акаунты. Тестировщики могут спокойно писать баг-репорты в Jira. Заниматься разработчик должен тем о чем сказал на стендапе. Вы описали не неопределенность, а бардак.
                                                                                          • +6
                                                                                            Я просто напомню с чего все началось.
                                                                                            > С чего вдруг менеджер должен публично брать на себя косяки программиста, не уложившегося в срок?
                                                                                            Если менеджер не может организовать работу программиста чтобы он укладывался в срок. Обратите внимание, не программист должен это обеспечить, а менеджер. Если менеджер не может вовремя уволить человека который не укладывается в сроки (когда то что мешает программисту устраняется, а программист все равно халявит) и заменить его другим. Если менеджер не заложил буферы на то, что время от времени задачи даже выполняемые повторно будут занимать больше времени по объективным причинам.
                                                                                            То? При чем здесь программист?
                                                                                            Вы не подумайте, у меня в подчинении очень хорошие программисты, которые эффективно делают свою работу. Но если один из проектов, за которые я несу ответственность не будет соответствовать заявленным требованиям (функциональным, нефункциональным, по срокам реализации, по бюджету), то ответственность перед заказчиками несу в первую очередь я. передо мной несут ответственность руководители проектов. А если мне руководитель проекта придет и скажет, что проект сфейлился, потому что Вася уже три месяца не делает вовремя порученные ему задачи. То надо уволить этого менеджера, т.к. он не решил проблему за 3 месяца, ну и следом меня, т.к. о том что на проекте 3 месяца идет отставание по срокам я узнал в день релиза.
                                                                                            • +1
                                                                                              Давайте так: отвечать должны и те и другие в рамках своих полномочий и прямых обязанностей. И закроем тему:)
                                                                                              • +1
                                                                                                Именно, каждый должен отвечать за свою часть общего дела. В пьесе представлены менеджеры типа «передасты». Которые кроме как передавать от руководства хотелки на разработчика, а оценки разработчика руководству — ничего не могут. А в случае проблем или ответственности пытаются их спихнуть на других.
                                                                                        • +2
                                                                                          Интересно, как разработчику запретить дергать себя другим людям? Вот посадило начальство 10-15 человек половина которых программисты, а вторая аналитики и менеджеры в один кабинет, и крутись как хочешь. В результате задачи на 30-40 минут растягиваются на все 8ч, из которых 6 часов тебя дергают разные люди с вопросами или левыми задачами (уточнить тп, рассказать как пользоваться фичей, нарисовать схему для заказчика, обсудить какие нибудь требования с заказчиком, подбежать с багом «ну тут же на 5 минут исправить, глянь по быстрому» и т.п.) и все это сопровождается постоянными телефонными звонками, гоготом, разговорами в стиле «а вокруг России одни враги, а Люба разошлась со своим то, а вот начальник из Москвы фотки из европы показывал», остальное время тратишь на вспоминание «а что же я там уже успел по задаче сделать» и на попытку внести задачи в систему тайм-трекинга. И потом еще виноват оказываешься что медленно работаешь, да еще и система тайм трекинга показывает дикие трудозатраты на получасовую задачу (не будешь же 5минутный разговор заносить, а требуется внести ровно 40 часов в неделю)
                                                                                          • 0
                                                                                            Я часто менеджеру и топ-боссам говорю: «разрешите мне работать из дома, не читать почту, игнорировать все сообщения/звонки от коллег кроме ваших лично и я сделаю эту задачу за неделю, если сами же другие задачи поручать не будете. А так, оптимистичная оценка — месяц, средняя — два». Раза три прокатывало, один из них, правда, сказали работать в офисе партнеров.
                                                                                            • 0
                                                                                              Ставьте себе график — 40 минут работаете, 20 — перерыв. Из них 10 — перекур/прогулка/чай/беседы на отвлеченные тем, 10 — преговоры с коллегами. Все не срочные вопросы перенести в текстовое общение и отвечать в асинхронном режиме. Довести до коллег свой распорядок. Во многих организациях такой распорядок закреплен руководством.
                                                                                              • 0
                                                                                                А коллегам чаще всего плевать( И они продолжают дергать.
                                                                                      • –3
                                                                                        В том-то и дело, что не отвечает в общем случае. Не должен отвечать. Он даёт прогноз, а не результаты спиритического сеанса. Вы же не считаете, что синоптики должны отвечать за результаты своих прогнозов? Или политические аналитики?
                                                                                        • +5
                                                                                          Тогда руководитель не отвечает за своевременность выплаты заработной платы, а менеджер за сроки проектов. Они дают прогнозы и гадают на картах Таро.
                                                                                          • –2
                                                                                            Руководитель отвечает за своевременность выплаты зарплаты. Вплоть до уголовной ответственности. А за что отвечает менеджер — это их договоренность с руководителем.
                                                                                          • 0
                                                                                            Простите, что вмешиваюсь в ваш спор.
                                                                                            Мне кажется, что разработчики часто не отвечают за свои прогнозы.

                                                                                            Но иногда отвечают и таких разработчиков ставят сеньорами и тимлидами.
                                                                                            • 0
                                                                                              Тимлидами ставят тех, кто готов отвечать за всю команду, как ни странно. И тимлид — уже скорее менеджер, чем разработчик. Почему я и отбрыкиваюсь от попыток делать меня тимлидом. Сеньором, архитектором, техлидом — пожалуйста. Но отвечать за свои, а, тем более чужие, прогнозы и, тем более, косяки — увольте. Не увольняют почему-то.
                                                                                              • 0
                                                                                                Прошу прощения. Программисты не должны отвечать за сроки.
                                                                                                Они должны отвечать за код!
                                                                                                Точнее за качество кода.
                                                                                                Чтобы при добавлении новой фичи
                                                                                                1) Количество ошибок на фичу не увеличивалось
                                                                                                2) Время на добавление фичи не росло в экспоненциально.
                                                                                                Потому что «выигранное» X времени сейчас, выльются в e^X потом.
                                                                                                • +2
                                                                                                  Поверьте на слово — идеальный код, законченный к моменту провала проекта — гораздо хуже, чем плохонький, но работающий и решающий чьи-то проблемы.

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

                                                                                                  В предыдущих комментариях, да и в тексте поста есть определенное недовольство тем, что менеджеры высасывают сроки из пальца. По вашему получается, что это нормальная ситуация.
                                                                                                  • 0
                                                                                                    В большинстве случаев объективной привязки (кроме бюджета на разработку и подобных финансовых кейсов) к каким-то датам нет, просто нужно как можно скорее. И менеджменту сроки окончания разработки нужны для привязки других мероприятий типа резервирования рекламных мест, набора расширенного штата, аренда новых помещений и т. п. Или наоборот, подготовки к сокращению штата и т. д. Менеджмент любит параллельные процессы, чтобы к моменту готовности продукта его сразу запускать в эксплуатацию, не неся дополнительных расходов за слишком раннее проведение других мероприятий и не теряя потенциального дохода за время простоя продукта из-за их неосуществления.
                                                                                                    • 0
                                                                                                      Ага. А потом менеджмент, который принимает слова программиста за чистую монету проводит массивную рекламную компанию в 1983м в то время как продукт выходит в 1985м. Собственно задача менеджера любой компании, которая что-то разрабатывает — научиться как-то с этим жить. И разработка нового сайта тут ничем не отличается от задачи разработки нового Boing'а: и там и там устраивать разработчикам разносы — лучший способ остаться с «разбитым копытом».
                                                                                                      • 0
                                                                                                        Вот в том-то и дело, что это задача менеджера, это его обязанность учитывать риски ошибочности оценок разработчиков.
                                                                                  • +1
                                                                                    Потому что определение подходящего срока — это ответственность менеджера. Программист — он код фигачит и о сроках имеет весьма приблизительное представление.


                                                                                    Надеюсь вы не имеете в виду, что сроки выполнения задач должны определять менеджеры вместо программистов?
                                                                                  • +1
                                                                                    Потому что программист срок в который он уложится обычно не называет. Он даёт вероятностную оценку трудозатрат (или вообще абстрактные поинты, привязанные к сложности), по которой менеджер, пользуясь своими профессиональными знаниями, навыками и опыту, сообщает сроки руководству. Очень часто в форме обязательства. Если сроки сорваны, то это ответственность прежде всего менеджера — неправильно оценил риски. И, скорее всего, не заметил имеющиеся признаки срыва заранее. Или заметил, но толком ничего не предпринял.
                                                                                    • +1
                                                                                      Думаю, вина не может быть абсолютной, все зависит от того, кто кому обещал и кто обещание не выполнил.

                                                                                      Разработчик обещает менеджеру, менеджер обещает начальству.
                                                                                      Разработчик виноват перед менеджером, менеджер перед начальством.
                                                                                      Если разработчик начальству ничего не обещает, то он перед ней и не виноват.

                                                                                      Думаю мыслю поняли.
                                                                                      • +2
                                                                                        У менеджеров и начальства есть склонность принимать оценки, планы, прогнозы за обещания.
                                                                                        • 0
                                                                                          Это нормально. Они сделали ставку на то, что разрабы, могут притворить эти планы и прогнозы в жизнь. В худшем случае ставка не сыграет.

                                                                                          Разработчик виноват в неверной оценке.
                                                                                          Руководство — в том, что доверилось прогнозу(оценке).

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

                                                                                          Начальство должно наказать менеджера, менеджер — подчиненного.
                                                                                          Будет печально если все шишки посыпятся только на разработчика.
                                                                                          • +1
                                                                                            Интересно, в чем виноват разработчик если он оценил фичу в неделю, менеджер сказал ок, навесил еще 2 задачи по два дня, и в итоге спрашивает в конце недели почему ничего не готово?
                                                                                            • 0
                                                                                              Он должен был отказатся от этих 2 задач.
                                                                                              Ну, или отложить релиз фичи. В таком случае об этом надо доносить, тому кому эта фича была «обещана».
                                                                                              • 0
                                                                                                А в том и проблема что бесполезно это объяснять. Особенно когда над головой несколько менеджеров, каждый свою задачу приоритетной считает, и каждый, несмотря на то что прямо заявляешь что это названное время работы — не срок, а именно время работы над задачей, будет ожидать результата через время названное разработчиком. Ну и отказаться возможности нет (даже временно), принцип: я начальник — ты дурак.
                                                                                                • +2
                                                                                                  Проблема даже не в том, что они ожидают через это время, а в том, что они ожидают, в лучшем случае, через это время по рабочему графику, а не по времени, затраченному на их задачу.
                                                                                    • +1
                                                                                      Хороший менеджер — это тимлид. И как раз ответственность тимлида оценивать сроки.
                                                                                      В случае же когда разговаривают менеджер и разработчик проблема не в менеджере и не в разработчике а в человеке, который поставил их разговаривать друг с другом.

                                                                                      Тимлид — человек вышедший из разработки, как правило половину времени уделяет распределению задач, написанию ТЗ, донесением до менеджеров и руководства всей сути технической работы)
                                                                                      • +1
                                                                                        Когда-то я был малым и глупым и работал в компании где директор разговаривал напрямую с разработчиком(мной, при этом еще студентом). Тогда разработчик сдуру согласился писать новый проект за пару недель, как очень хотело руководство. Удивительно, но проект не был закончен вовремя и разработчику предложили поработать еще в режиме 18 часов кодинга в день 7 дней в неделю. После этого последовало очень неожиданно для директора последовало ПСЖ.

                                                                                        Так что да, в компаниях где нет тимлида самое разумное действие разработчика — писать ПСЖ. А еще лучше даже не пытаться устраиваться в такую компанию.

                                                                                        P.S. После этого наняли тимлида и переписали и старый и новый проекты с Явы на C++. Потому что новый тимлид не знал Яву) И это все равно было лучше, чем без тимлида.
                                                                                        • +2
                                                                                          P.P.S Менеджер в компании тоже был и пытался решить провал сроков путем введения мегаплана(не джиры, не гита — мегаплана) и отчетности. После этого разработчик даже на диалог не захотел идти)
                                                                                      • 0
                                                                                        хороший считает (и не в глубине души, а публично заявляет), что это его ошибка, что он оценку разработчиков выдал за свое обязательство.

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

                                                                                        • 0
                                                                                          О, если бы менеджеры четко следовали этому правилу, называть время стоило бы с миллисекундах.
                                                                                          Там разрыв с единицей времени более высокого порядка посолидней будет, чем по другим вариантам.
                                                                                          • 0
                                                                                            Прекрасная иллюстрация никчемности этого правила.
                                                                                          • +1

                                                                                            <irony>10 килосуток (30 лет)?</irony>

                                                                                    • 0
                                                                                      Обычно программисты имеют низкий социальные навыки

                                                                                      Сморозили чушь, наделали ошибок, да еще и полхабра оскорбили. Nice work!

                                                                                      • –1
                                                                                        Вы либо толстый зеленый тролль, либо феерический долбоеб.

                                                                                        Простите меня за мой французский, но я безмерно возмущен!
                                                                                        • 0
                                                                                          Минус вам в карму. Я не согласен с Saffron, но не хотел бы видеть на Хабре комментарии, подобные вашему.
                                                                                          • +1
                                                                                            Право, милейший, но я же извинился!
                                                                                        • 0
                                                                                          Это значит то, что менеджер:
                                                                                          — не прислушивается к своим разработчикам (грубо говоря, не доверяет).
                                                                                          — боится, что правильный подход будет слишком сложным для начинающего чайника, который заменит разработчика (если тот уйдёт).
                                                                                          — пытается применить к новому проекту свой совершенно нерелевантный опыт из старого проекта, который был сделан из совершенно другого конструктора.

                                                                                          и ещё тысяча других причин.
                                                                                        • +6
                                                                                          Надо что-то делать с текстом, а то слово «говно» в нем уже стало техническим долгом. То «гавно», то «говно» — вы уж на гОвно замените везде.

                                                                                          Или это как пример технического же долга?
                                                                                          • +5
                                                                                            Как пример технического долга я вставил off by one error в нумерации частей. Спасибо что заметили.
                                                                                            • +2
                                                                                              Спасибо за момент, когда пол-ежа заливают сверху говном. Это — самое жизненное.

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

                                                                                              Разраб, когда после совещания отошел немного, пошел и написал «по собственному».
                                                                                              • +1
                                                                                                Нужно было внести встречное предложение:
                                                                                                Менеджер, получавший 70 тысяч, буде получать 4464. Чтобы не ругались на ошибки переполнения.
                                                                                          • +1
                                                                                            Неплохо и довольно жизненно)
                                                                                            • +3
                                                                                              > система КРОТОПОН, которая работает на продакшане заглючила и мы потеряли кучу денег.

                                                                                              Так и не смог разгадать ребус и вычислить название реальной системы(
                                                                                              Поделитесь? )
                                                                                              • +4
                                                                                                Видимо это гибрид крота и пони — слепой, слабый, полон рюшечек и работает только когда его никто не видит.
                                                                                                • +1
                                                                                                  Сначала подумал, что это аллюзия на
                                                                                                  Страпони
                                                                                                  image
                                                                                                • +5
                                                                                                  • 0
                                                                                                    Ну какая платформа (см Генезис), такие и прикладные проекты на ней.
                                                                                                  • +1
                                                                                                    До слёз
                                                                                                    • +1
                                                                                                      спасибо, у меня сейчас такой сценарий разыгрывается :) уже второй менеджер :))
                                                                                                      • +6
                                                                                                        Всё верно, кроме последнего абзаца. Компания не разоряется, продукт-то работает. Ну и пофиг что костыли, ынтырпрайз же. Продукт продают, для поддержки достаточно макак. Опять же на премии и повышении сэкономили.

                                                                                                        Так оно и задумывается на борде, ваще та. А готового выгореть разраба можно и нового найти.
                                                                                                        • +15
                                                                                                          image
                                                                                                          • +6
                                                                                                            Довольно поучительно и наглядно для демонстрации того, к чему приводит длительное забивание на технический долг. Однако, довольно сильно идеализировано, и менеджер все-таки чересчур демонизирован( хотя, в этой конкретно ситуации он реально самодур). Все это похоже на разработку какого-то внутреннего продукта больше для нужд самой компании. А давайте представим, что где-то в антракте между третьей и четвертой частью ( наиболее подходящее место, как мне кажется ), на сцену врывается Конкурент (К), и начинает неистово рекламировать свой ( как потом окажется, не совсем еще стабильный, но пофигу — главное, сейчас нишу захватить и пользователя подсадить. И пофигу, что костыли — они же у нас армированные(!), потом заменим ) продукт, да еще со скидкой, да еще с бесплатным тестовым периодом. В результате, начиная с 4-й части, менеджер будет где-то вынужден идти на «непопулярные» меры, в противном случае проект ( а может, и компания ) рискуют не дожить до концовки пьесы, ибо продукт-то хорош, а толку-то с него, аудитория уже захвачена и накрепко подсажена на продукт К, а ресурсов ждать, пока пользователь осознает, какие вы крутые, и продвигать эту свою крутость в массы, попросту нет. Ввиду пока еще высокой динамики развития отрасли ИТ такой сценарий видится гораздо более реальным, да и практика показывает то же самое.

                                                                                                            Идеальный управленец вообще не должен иметь конфликт интересов со своими разработчиками. Наоборот, он должен быть арбитром между конечным заказчиком/пользователем и своей командой. Но это в идеале. А так то, что довольно часто проект становится жертвой субъективизма менеджмента, тут вы правы, ничего не поделаешь…
                                                                                                            • +1

                                                                                                              Неспроста ж случается, что з/п у П бывает повыше чем у его М.

                                                                                                              • 0
                                                                                                                Хорошо еще что только до М3 добрались, а не дальше. Сполз под стол, спасибо!
                                                                                                                • 0
                                                                                                                  А это рекурсивный алгоритм
                                                                                                                  • 0
                                                                                                                    Не, цикл :) Хотя, да, цикл можно заменить рекурсией.
                                                                                                                • +1
                                                                                                                  Очень жалко программиста :(
                                                                                                                  • –5

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

                                                                                                                    • +3
                                                                                                                      не всегда. Частенько в объявлении персонажей присутствует и краткое описание
                                                                                                                    • 0
                                                                                                                      спасибо. просто спасибо!
                                                                                                                      • +1

                                                                                                                        У меня немного другая история была, как-то 1.5 года оттимлидил на проекте где 3 ПМа сменилось, причем не с повышением, а с увольнением ПСЖ. Ситуацию они особо не контролировали, но служили неплохим буфером между заказчиком и командой разработки. Когда случались факапы (а случались они постоянно :)), они самоотверженно получали люлей, потому наверное и не выдерживали подолгу… Ну а в целом проект закончился успешно, стал хорошим пунктом в моем CV, и я благодарен этим ребятам за то что спасали мою нервную систему.

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