Пьеса «Технический долг» в 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 пишет записку «Так как Разработчик был недостаточно лояльным и уволился прошу выделить мне команду для поддержки этого приложения а пока мы замораживаем все работы по нему».
Через пол года всё рассыпается и компания теряет много денег. Обвиняют во всём уже ушедшего из компании Разработчика и решают сделать новую систему, так как никто не понимает как работает старая.
КОНЕЦ
При написании этого текста не пострадал ни один костыль.
Все совпадения с реальными людьми и событиями считать злонамеренными.
Комментарии (177)
Saffron
11.01.2017 19:47-52Как-то вы излишне демонизируете менеджеров, будто они совсем не заинтересованы в успехе проекта.
Обычно, если менеджер принимает неверное решение, это значит, что программист не смог донести всю тяжесть последствий. Обычно программисты имеют низкий социальные навыки, так что нужен специальный человек, для донесения до начальства мыслей о технической составляющей проекта.
Таких людей часто выделяют всякие оутсорсерские и облачные конторы. Они приезжают к начальству и рассказывают душераздирающие истории о том, что может пойти не так, с графикам и таблицами, как положено, и убеждают менеджеров больше тратить на IT.JediPhilosopher
11.01.2017 19:59+70Обычно, если менеджер принимает неверное решение, это значит, что программист не смог донести всю тяжесть последствий.
— Аааа, у нас на проекте все очень плохо, почему ты не предупредил что так может быть?
— Но я же говорил что будет плохо если не сделать то и то…
— Да, но ты не говорил что будет ОЧЕНЬ плохо. Ты не старался до меня донести! Ты во всем виноват!Saffron
11.01.2017 20:34-20Ну надо понимать, с кем ты разговариваешь. Что для тебя очевидно, для него может быть нет. Он небось и считать умеет только до десяти, и математику последний раз видел в 9ом классе.
khim
11.01.2017 21:19+21Он небось и считать умеет только до десяти, и математику последний раз видел в 9ом классе.
Тогда почему он считает что он может решать, что нужно делать, а не я? И почему он вообще принимает какие-либо решения, если я должен до него «доносить» какие от них могут быть последствия?Saffron
11.01.2017 22:00-25Потому что он умеет и не боится взаимодействовать с неидеальным внешним миром и ориентироваться на результат.
Потому что даже когда хорошие друзья хотят вместе выбраться на пикник, должен найтись хотя бы один человек, который будет всех непрерывно пинать и напоминать об их желаниях, координировать планы.
marshinov
11.01.2017 22:41+7Справедливости ради стоит отметить, что бывают (редко) менеджеры, вышедшие из разработчиков: это типа как мульти-класс в AD&D: качаешься до 10 lvl «Разработчиком», а потом получаешь новый класс и снова до 10 с нуля: долго, сложно, зато в конце получается не специалист, а конфетка. Времени на это правда уходит вагон и маленькая тележка.
merom3ro
12.01.2017 09:33+5Очень много историй, как разработчики уходят в менеджеры, считая это развитием, а в итоге оказываются жестко ограничены окружающими условиями и перестают развиваться. За это время выходит тысяча новых фреймворков, меняются тренды и ценность этого человека как программиста безнадежно падает (причем наверняка не объективно, а лишь в глазах М1-М3).
White_Scorpion
12.01.2017 19:28+1Даже если разработчик «устаревает» — он всё равно лучший менеджер потому что он более в теме, чем просто чистый манагер. Тупо потому, что он понимает, что вот взять вот этот кусок говна с костылями и «прикрутить к нему фигулинку» — это не «5 минут… ну максимум час, что тебе сложно что ли? Мы же так уже делали в проекте ААА, а здесь — точно так же». Он знает, что «точно так же» — нифига не так же, знает, что из процесса разработки — нельзя выкинуть «неважные детали» типа тестирования. И ещё много разных «он знает, что ...».
SurfCalavera
12.01.2017 19:28+1так они уходят за разитием себя в смысле карьеры или личных целей, а не в смысле развиваться как «еще более лучший»™ программист.
поддерживать ценность себя как программиста после перехода в менеджмент это нерациональное использование ресурсов.
merom3ro
13.01.2017 10:10Вы не совсем верно меня поняли. Я говорил именно о том, что разработчик уходит в менеджеры ради карьерного роста и личных целей, пологая что завис в пространстве, работая разработчиком. И в итоге попадает в комнату со стеклянным потолком: его вроде как и не видно, но он очень сильно ощущается. После этого он понимает, что пути развития в роли разработчика у него были, а в роли менеджера он действительно не может двигаться дальше. Я не утверждаю, что это верно для всех ситуаций, а всего лишь говорю, что такое происходит и даже не раз было описано на хабре/гиктаймс.
SurfCalavera
16.01.2017 01:38ну это фундаментальное изменение, честно говоря я не думаю, что такого уровня непонимание развития карьеры часто встречается.
неправильная оценка того что хочешь это да (хочу руководить, а на самом деле нет), но вот что путь к разраб 80lvl -это через менеджера, такое думаю редко.
VolCh
13.01.2017 10:31поддерживать ценность себя как программиста после перехода в менеджмент это нерациональное использование ресурсов.
Как показывает хотя бы этот топик, менеджер с актуальными навыками программирования и всего вокруг него более востребован программистами как начальник (product owner в SCRUM). Субъективно, у такого менеджера доля успешных проектов и удачных спринтов будет выше.SurfCalavera
16.01.2017 01:32более востребован программистами как начальник
ну тут наверное важнее востребованность у бизнеса, а не у программистов, поскольку это бизнес платит в конце то концов.
да и актуальность навыков изчезнет за полгода-год.
но да, программистам наверное будет приятнее, мол «свой человек когда-то был».
хотя может и наоборот «вроде свой человек, должен понимать, а он!!»
(SCRUM product owner — это не менеджер все же)
в любом случае, переход раработчик-менеджер это не развитие карьеры разрботчика, это фундаментальное изменение, и жаль когда разработчики в попытках развить карьеру этого не понимают.
VolCh
16.01.2017 10:17Программисты разбегутся и бизнесу и начальник не нужен будет. То есть востребованность программистами определяет и востребованность бизнесом. Не обязательно это ключевой фактор, но важный.
(Как не менеджер, если принимает бизнес-решения по распределению ограниченных ресурсов?)
Тут зависит от того, что считать разработкой. Например, вот начал я работать один над проектом (веб-приложение в интранет), начал зарываться со временем — с одной стороны обычный поток задач, связанных с развитием бизнеса, с изменением законодательства и т. п., с другой — хотелки стейкхолдеров, которые наконец-то получили человека, который успешно их реализует. Анализ ситуации показал, что много времени уходит на рутинные задачи по фронтенду, взяли мне в помощь фронтендера. Я ставлю ему чёткие задачи с указанием необходимого мне пути решения, вплоть до ссылок на библиотеки, которые надо использовать, он их выполняет. Можно ли сказать, что я перестал заниматься разработкой фронтенда? Код писать перестал почти, а вот разработкой, по-моему, не перестал заниматься. С другой стороны, можно ли сказать, что я стал менеджером? Как по мне, то стал. Я делегирую ему решение своих подзадач, ставлю приоритеты, контролирую прогресс и качество, отвечаю по сути за результат его работы. Чем не менеджер?
skabbit
12.01.2017 08:58+13Потому что он умеет и не боится взаимодействовать с неидеальным внешним миром и ориентироваться на результат.
Это такая идеальная отмазка, чтобы скрыть некомпетентность руководства?Saffron
12.01.2017 09:25-10Если у тебя есть все необходимые компетенции, то почему ты сам не пошёл в руководство? Программистам не нравится работать менеджерами, применять необходимые для этого навыки. Вот к ним и приходит менеджер со стороны, чтобы заполнить вакансию. Может он вообще программы не выпускал, а дороги катал или катком заведовал. Он имеет все необходимые знания для менеджера, но не имеет опыта в конкретной предметной области.
skabbit
12.01.2017 11:58+2Ну пусть катает дороги дальше.
Или в нашей удивительной стране кухарки могут управлять не только государством, но и высокотехнологичным производственным процессом?
PS: У меня нет необходимых компетенций, чтобы быть в руководстве, у меня есть компетенция в области разработки ПО. Потому и не иду.Saffron
12.01.2017 12:23-5А что в вашей удивительной стране программисты после выпуска из вуза знают сразу 100500 языков и фреймворков, каждую предметную область, от вебсайтов до микроконтроллеров, от игрушек до геораспределённых систем? Могут использовать любую известную базу данных или изготовить свою?
Нет. Так зачем же требовать от менеджеров всезнания? Помогайте ему по мере ваших сил, у вас один проект и одна цель!skabbit
12.01.2017 12:50+3Как-то Вы лихо с больной головы на здоровую. Задело, что ли? Не хотел, честно.
Я же не требую всезнания от менеджеров, я требую компетенции в заявленной области. Думаете, я не видел программистов, которые заявляли больше, чем умели?
Ipeacocks
12.01.2017 14:04+2Вы сравниваете менеджера, который пришел с укладки дорог, и программиста, которіе не знает все фреймворки? Это, по-вашему, хорошая параллель?
Saffron
12.01.2017 15:51-5Ну а что, сейчас менеджеры прям при выходе из менеджерских ВУЗов в курсе как работают кодеры в IT? Они же не знают, где ещё будут применяться их знания, основной их навык — это «программирование» людей. А на какую задачу их нужно будет программировать, наперёд не известно.
Точно так же как выпускнику прогерского ВУЗа не известно, какой ему придётся JS движок использовать в работе. Научится по дороге.poxu
12.01.2017 16:16+11Они же не знают, где ещё будут применяться их знания, основной их навык — это «программирование» людей. А на какую задачу их нужно будет программировать, наперёд не известно.
Ну вот, собственно, этим всё сказано. Приходит такой менеджер на производство и начинает наносить непоправимую пользу. Если команда хорошая — он не сильно много пользы нанесёт, если не такая хорошая, то у конторы сразу проблемы.
Всё из-за подхода — я программирую людей, зачем мне знания в области, в которой я руковожу.
Argutator
12.01.2017 18:54+3У менеджеров, на минутку, тоже есть специализации типа «управление машиностроительным производством», где как раз таки понимание особенностей работы и организации работ в данной отрасли очень важно. Без этого понимания и будет получаться что «Возьмем 9 беременных женщин и родим ребенка за месяц. Ну а чо, я ж не биолог.»
VolCh
12.01.2017 15:57Проект, может, и один, а вот цели не совсем одни. На многих проектах менеджерам важнее сроки и большой список фич, чем пустой список багов.
szubtsovskiy
14.01.2017 21:57+2В пьесе описан менеджер, который, не являясь компетентным, не слушает того, кто является компетентным. В этом-то и проблема.
От менеджера не требуется всезнание — от него требуется коммуникация не только с начальством, но и с подчинёнными. Только в этом случае это один проект и одна цель. А то, что описано в пьесе, больше похоже на «я начальник, ты дурак». Это не один проект и одна цель, это — спущенная сверху разнарядка, от реальности очень сильно оторванная.
Ты можешь не знать всего — и это нормально — но если проект для тебя значит больше, чем собственные амбиции, ты будешь слушать своих подчинённых и опираться на них, а не приказы начальства. Если же впереди амбиции, то получается ровно то, что описано в пьесе. И цена такому менеджеру — нуль. Вне зависимости от его знаний и опыта. Не надо искать оправданий очевидной некомпетентности.
Ipeacocks
12.01.2017 14:01+1> Он имеет все необходимые знания для менеджера, но не имеет опыта в конкретной предметной области.
Ну вот потому такого менеджера и не следовало бы брать в ИТ.
DarthVictor
12.01.2017 14:38+4Программистам не нравится работать менеджерами, применять необходимые для этого навыки.
Полагаю у вас однобокая статистика. Все менеджеры кроме одного с которыми я работал, будучи разработчиком, были либо бывшими либо действовавшими программистами. И проект знали или на уровне разработчика или на уровне администратора. И это опыт по трём компаниям и полудюжине менеджеров.khim
12.01.2017 16:10+5Работающие в таких компаниях обычно не пишут подобные статьи.
Речь идёт об «эффективных манагерах», которые, по сути применяют один и тот же алгоритм:
1. Корову меньше кормить и чаще доить.
2. Получить бонус на «эффективность».
3. Вовремя свалить (в идеале — на повышение).
Для этого, в сущности, знаний не нужно — достаточно звериного чутья. Потому что пунк #3 — ключевой.
istinspring
13.01.2017 05:16-1+1 немного поработал в нескольких стартапах из США (удаленно, но все же), возможно не все, но часть практикует «горизонтальную» структуру управления, когда тебе звонит по скайпу инвестор-менеджер проекта и он может не имеет обширной практики программирования на языке X, но прекрасно разбирается в терминологии и software development в целом и говорить с ним можно на техническом сленге, без всяких скидок — «ну он же не понимает». И как правило проекты под руководством таких менеджеров заканчиваются успешно, чего не скажешь о тех «менеджерах» которые лезут «руководить» в той области в которой не разбираются.
Wesha
13.01.2017 04:38VolCh
13.01.2017 10:33+1С другой стороны, эта система уже может приносить деньги, которые полностью окупят дальнейшие затраты.
jetexe
13.01.2017 10:40+1а потом момент упущен, рынок перенасыщен, затраты на маркетинг увеличиваются на порядок (а то и на несколько). И в конечном итоге выходит, что нафиг никому не нужен ваш чистовылезанный проект. Как бы самому не было противно, но таковы реалии
DemetrNieA
11.01.2017 20:14+28Они не заинтересованы в том, чтобы проект не провалился.
Это такая дилемма миддл менеджера: единственный способ быть замеченым и получить повышение — это когда проект удаётся и привлекает внимание высшего начальства (т.е. в сжатые сроки, приоритетное направление, и т.д.), а неудачи не приводят к плохим последствиям, т.к. можно размазать ответственность и вообще иногда неудачи — это даже хорошо, т.к. можно попросить больше денег и привлечь внимание к себе.
Такое состояние приводит к тому, что возникает конфликт интересов и им субъективно выгодно принимать рисковые решения.
sshikov
11.01.2017 20:20+17>Как-то вы излишне демонизируете менеджеров, будто они совсем не заинтересованы в успехе проекта.
Неа. На самом деле все еще хуже. Вот совершенно реальный разговор из жизни:
П: можно сделать вот так, и тогда мы релизимся через неделю, или вот так — и тогда релиза не будет через три месяца.
М: хорошо, делаем по варианту два, три месяца это вы пессимист, сделаем за два.
Проходит три месяца. Релиза нет, и непонятно когда будет.
Менеджеру не нужен успех проекта. Менеджеру не нужен качественный код. Ему нужно выбить деньги на проект, и потом их потратить, а в случае проблем — свалить вину на кого-то другого, и выбить денег на исправление проблем. Я не хочу сказать, что это всегда так — но увы, это достаточно типично.
P.S. Пока писал, появился комментарий выше. И я с ним согласен — конфликт интересов что-то слишком типичен.
avbochagov
11.01.2017 21:18+86Притча "Менеджер и программист"
Человек, летящий на воздушном шаре, обнаружил, что потерялся. Он спустился немного ниже и заметил на земле женщину. Спустившись ещё чуть ниже, он обратился к ней:
— Простите, не могли бы вы помочь? Я договорился с другом встретиться час назад, но не знаю, где сейчас нахожусь.
— Вы находитесь на воздушном шаре в 30 футах от поверхности Земли, между 40 и 41 градусом северной широты и между 59 и 60 градусом западной долготы ответила женщина.
— Вы, должно быть, программист?
— Да, а как вы догадались?
— Вы мне дали абсолютно точный ответ, но я совершено не представляю, что делать с этой информацией, и я всё ещё потерян. Откровенно
говоря, вы мне совершенно ничем не помогли.
— А вы, наверное, менеджер?
— Да. А вы как догадались?
— Вы не знаете, где находитесь и куда направляетесь. Поднялись вы туда, благодаря воздуху. Вы дали обещание, которое не представляете, как выполнять, и ожидаете, что люди, которые находятся ниже вас, решат ваши проблемы. И, наконец, сейчас вы в том же самом положении, в котором находились до встречи со мной, но почему-то теперь в этом оказалась виновата я.
Просто почему-то вспомнилось...
skabbit
12.01.2017 12:00+12О боги, спасибо!
Через 20 лет я узнал, что у анекдота есть продолжение ("— А вы, наверное, менеджер?")
Wesha
13.01.2017 04:59+3> Поднялись вы туда, благодаря воздуху.
В английском оргинале «you got where you are thanks to a lot of hot air» — тут идиома, на русский в целом переводится как «вы оказались на своей высоте [(должности)] благодаря тому, что много заговаривали зубы/пудрили мозги», но в переводе на русский игра слов с «горячим воздухом» пропадает :(dimm_ddr
13.01.2017 10:53Я сначала так же подумал, но ведь есть же идиома «торговать воздухом», с натяжкой конечно, но в общем смысл именно в таком переводе есть.
VolCh
11.01.2017 22:29+4Обычно менеджерам сообщается что-то вроде: эта фича займёт от 40 до 120 часов. Они докладывают наверх: будет готово через неделю, может 10 дней. И при этом постоянно подгружают мелкие задачки на час-два в день, ежедневные совещания на полчаса по фиче, пару совещаний по будущим задачам по часу. Какие ещё скилы нужны от разработчика, чтобы менеджер 120 разделил на, максимум, 6 часов и получил срок в месяц?
marshinov
11.01.2017 22:44-1Так-же часто бывает обратное: менеджер закладывает 200 и все-равно не успевают
VolCh
12.01.2017 05:09+7Бывает, да. Но в чём отличие хорошего менеджера от плохого — хороший считает (и не в глубине души, а публично заявляет), что это его ошибка, что он оценку разработчиков выдал за свое обязательство. Плохой же менеджер заявляет, что разработчики не выполнили свои обязательства, а он не причем, он лишь проинформировал руководство об обязательствах разработчиков, да ещё заложил риски, но разработчики всё равно не выполнили свои обязательства.
skabbit
12.01.2017 09:01Спасибо, прекрасный критерий.
VolCh
12.01.2017 10:28Вообще армейский критерий :) С другой стороны, офицер, командир подразделения — это тоже менеджер.
marshinov
12.01.2017 10:43+1Это плохой критерий, потому что остальные члены команды не чувствуют никакой ответственности и причастности к результату.
poxu
12.01.2017 11:16+3А то, что они этого результата собственно и достигают — это не считается?
marshinov
12.01.2017 11:25+3Результат достигается совместными усилиями команды: разработчиками, менеджерами, аналитиками, тестировщиками, дизайнерами, проектировщиками, ..., а не только программистами. Это без учета сейлзов, без которых вся эта команда сидела бы и сосала лапу.
Брукс и Гласс, например, сходятся в оценке того, что «выпустить продукт» требует примерно в 6 (шесть, Карл!) раз больших трудозатрат, чем «написать код». Поэтому логично, что и ответственность лежит на команде, а не на менеджере.
Конечно, в случае факапа, голова должна лететь в первую очередь с плеч менеджера, потому что его основные функции — планирование сроков и бюджета и управление рисками. Поэтому «правильный» менеджер видит, что кто-то из членов команды «факапит» не перед дедлайном, а своевременно. И в этом случае он не ответственность на себя будет брать и публичные заявления анонсировать, а люлей раздавать, а в случае необходимости и менять конфигурацию команды так, чтобы сроки и бюджет «сошлись».
Тут комменты посмотришь: разработчики все сплошь на галерах гребут, напрягаются во благо компании, а менеджеры смузи только пьют.skabbit
12.01.2017 12:03+5Вы скажите, где менеджеры «правильные» и ведут себя так, как Вы описали. И есть ли там открытые вакансии? :)
TerraV
12.01.2017 12:20+2Про совместные усилия впаривают менеджеры когда надо выйти в выходные. А по ФОТу явно видно, что программисты просто налипли на проект и ничего существенного сделать могли в принципе. Как вам 3 ведущих менеджера, 4 рядовых менеджера на команду из 7-9 разработчиков, 2.5 тестеров и 0.5 аналитика?
marshinov
12.01.2017 12:24Я думаю, что на эту команду нужно 1 или 2 менеджера-администратора. 4 — много. При условии, что среди 7-9 разработчиков есть тимлид один.
TerraV
12.01.2017 12:29только не 4 менеджера, а 7.
marshinov
12.01.2017 12:30А там еще 3 ведущих))) По одному на разраба. Не знаю, это странно. Что они делают у вас?
TerraV
12.01.2017 12:45Я уволился :-) Насмотрелся на весь этот треш и ушел. Точнее как получилось, после закрытия проекта пошел к руководству разговаривать о ЗП, мне сказали что я охренел вконец и хоть весь наш отдел строем уволится, работать всегда будет кому. Или средняя по городу, или по собственному. На улице очередь стоит. Я перешел на удаленку, ЗП в 3 раза выше геммора в 10 раз меньше.
P.S. мне эти менеджеры казались виртуальными. я их не видел. может просто чтобы освоить бюджет проекта.
VolCh
12.01.2017 16:08Каждый в команде отвечает за свою часть результата. В частности разработчики за выполнение технических требований и качество кода. За сроки разработчики не отвечают, за соответствие бизнес-требований техническим — тоже.
marshinov
12.01.2017 10:41+1С чего вдруг менеджер должен публично брать на себя косяки программиста, не уложившегося в срок? Если «поеахал» критический путь проекта — это ошибка менеджера. Не уложился в оценку — либо ошибка планирования, либо не соответствие занимаемой должности. Способы ослабления рисков не верной оценки известны. В статье автор явно сгущает краски: программист у него лапочка и делает все во благо компании, а менеджер — некомпетентный тиран, угнетатель. В реальности дефицит хороших кадров в IT и в разработки и в менеджменте.
Saffron
12.01.2017 10:48+4> С чего вдруг менеджер должен публично брать на себя косяки программиста, не уложившегося в срок?
Потому что определение подходящего срока — это ответственность менеджера. Программист — он код фигачит и о сроках имеет весьма приблизительное представление. А менеджер как раз должен заниматься планированием производства, предугадывать косяки и усложнения по ходу дела, трезво оценивать потенциал вверенных ему программистов. Постоянно с ними общаться и убеждаться, что они не утратили видения того результата, который надо получить, и не закопались во второстепенные таски.
Программист, конечно, тоже может быть виновен в срыве сроков — если он вместо кода фигачил в танки. Но в большинстве случаев провал сроков — это провал планирования и ошибка менеджера.marshinov
12.01.2017 11:05+2Ок, если так, то почему вы удивляетесь, что менеджер, имеющий слабое представление о технических деталях, назначает неадекватные сроки, если не хотите брать хотя-бы частично ответственно за оценку задач на себя?
Менеджер подключен к космическому знанию, предвидит будущее и так планирует сроки? Если нет, то на основании каких данных производится планирование?
Программист может оценить задачу, потому что у него есть опыт реализации аналогичных задач (если мы говорим про профессионала). Я оцениваю типовые задачи с точностью до минут. Не типовых задач в энтерпайзе на самом деле не так много, как принято считать.Saffron
12.01.2017 11:22+4Потому что если я могу вести и планировать весь проект целиком, то зачем мне менеджер?
Точное повторение старых действий (при условии неизменности окружения) — это залог идеального планирования.
А что если повторения нет, если задача отличается от той, что ты решал до этого? Нужна другая архитектура, другие библиотеки, у каждой — непредсказуемые временные затраты на внедрение. Как быть в этом случае? Программист может прикинуть лишь примерно, а затраты времени могут расти как фрактал.
Вот для этого нужен менеджер, он будет принимать решения в условиях недостатка информации. При этом он, конечно, должен извлечь в диалоге максимум информации из программиста, даже если программист стесняется говорить и пытается обойти некоторые моменты.
Потом менеджер должен решить, насколько важен проект, нужно ли закладывать больший запас ресурсов или провал сроков не критичен, и перезакладываться не нужно. Если менеджеру всё ещё слишком не понятно, сколько времени будет уходить на задачи, он может отловить программиста и вместо программирования посадить его за дизайн. Расписать вместе возможное разложение задачи на подзадачи, найти те, которые уже раньше делались и хорошо предсказываются, изолировать те, что предсказываются плохо — с ними продумать отдельно. Но это уже будет решение менеджера, ещё до начала проекта, потратить время программиста вместо программирования на анализ. Программист сам такого решения принять не может.marshinov
12.01.2017 11:30Для этого нужен не менеджер, а архитектор. Менеджер не знает всего этого: он наймет правильного человека, получит оценки и проанализирует риски. Ничего более точного еще не придумали.
Мы говорили, не про оценку всего проекта, а про то что нужно укладываться в оценки по своим задачам. Планировать весь проект разработчика ни один грамотный руководитель не попросит.Teacher
12.01.2017 15:39Э… Извините, что? Менеджер не знает, что такое иерархическое дерево работ? Да, для его построения ему нужен специалист в разработке, к которому он придет с верхнеуровневым деревом (эпики, фичи, стори), а тот уже разобьет на тривиальные оценки.
Правда, эта вся фигня с диаграммами Ганта выглядит красиво в ПМБуке, в Прожекте каком-нибудь, а вот в реальном проекте вдруг выясняется, что заказчик хотел не этого, а вот того. Это должно быть не так, а вот этак. Ну и все первоначальные оценки или идут в корзину, или идет торг на уровне «мы сделаем это, но выкинем вот это», или идет раздувание сроков-бюджетов. Там куча всяких интересных вариантов. Опять же будет своя специфика с внутренней разработкой, продуктовой, заказной. Не зря же пытаются всякие итеративные, инкрементальные способы разработки внедрять. Как раз из этих соображений, что самая адекватная оценка, это оценка полученная в процессе работы. Да и чем дольше идет проект, тем лучше предсказание рисков и все такое.marshinov
12.01.2017 15:55А что если повторения нет, если задача отличается от той, что ты решал до этого? Нужна другая архитектура, другие библиотеки, у каждой — непредсказуемые временные затраты на внедрение. Как быть в этом случае? Программист может прикинуть лишь примерно, а затраты времени могут расти как фрактал.
Я имел в виду, что разработчик отвечает за свои оценки. Остальное, видимо, все поняли по-своемуTeacher
12.01.2017 15:59+2Я разработчик, я отвечаю за свои оценки. Приходит ко мне менеджер и говорит: «Сколько?»
Ну я же отвечаю, за свои оценки, поэтому я, прикинув, что задача на 2 часа, но придет менеджер Петя и попросит подсказать как сделано А, потом забежит аналитик Света и попросит посмотреть нормальное ли требование Б, потом может быть недоступен тестовый стенд, дам оценку в 10 часов.
Что скажет на это менеджер?marshinov
12.01.2017 16:28-1Это все хрень. Организуйте свою работу так, чтобы тестовый стенд работал и Васи и Светы не забегали и делайте за 3 часа.
Teacher
12.01.2017 16:39+9Э… Я как разработчик должен организовать свою работу так, чтобы меня не дергали менеджеры, аналитики, тестировщики, заказчики. Точно? За это отвечает не менеджер? Т.е. я должен послать вас когда вы придете ко мне за оценкой? Так? Если да, то зачем вы пришли?
Я как разработчик должен договориться с отделом эксплуатации чтобы мне развернули нужный тестовый стенд или это ваша работа как менеджера?
Чтобы не было недоразумений, я уже лет 7 как менеджер, а первые подчиненные у меня появились лет 15 назад.
Мы живем в мире с высокой неопределенностью. Разработчик дал вам оценку в 16 часов. А потом у него подскочила температура и он ушел в больницу. Вы его не отпустите? Или это он виноват, что не решил задачу за 16 часов?marshinov
12.01.2017 16:43Я говорю только про риск «низкая производительность труда». Падения метеоритов, температура и прочее случаются. Все это понимают.
И я про 3 часа которые в ворк-логах, а не календарные.Teacher
12.01.2017 17:06А теперь как только на задачи которые я оцениваю в два часа, я буду ставить три, то быстрее трех я ее делать не буду. Ведь так? А потом я буду на эту задачу (помня что она занимает три часа) говорить четыре. Да? И вас это будет устраивать?
marshinov
12.01.2017 16:47Если разработчику мешают и поэтому он не укладываются, нужно сказать, так и так я по факту не работаю, а болтаю с аналитиками и отделом внедрения. Светку надо уволить, потому что дура она, а не аналитик. С заказчиками должны общаться акаунты. Тестировщики могут спокойно писать баг-репорты в Jira. Заниматься разработчик должен тем о чем сказал на стендапе. Вы описали не неопределенность, а бардак.
Teacher
12.01.2017 17:15+6Я просто напомню с чего все началось.
> С чего вдруг менеджер должен публично брать на себя косяки программиста, не уложившегося в срок?
Если менеджер не может организовать работу программиста чтобы он укладывался в срок. Обратите внимание, не программист должен это обеспечить, а менеджер. Если менеджер не может вовремя уволить человека который не укладывается в сроки (когда то что мешает программисту устраняется, а программист все равно халявит) и заменить его другим. Если менеджер не заложил буферы на то, что время от времени задачи даже выполняемые повторно будут занимать больше времени по объективным причинам.
То? При чем здесь программист?
Вы не подумайте, у меня в подчинении очень хорошие программисты, которые эффективно делают свою работу. Но если один из проектов, за которые я несу ответственность не будет соответствовать заявленным требованиям (функциональным, нефункциональным, по срокам реализации, по бюджету), то ответственность перед заказчиками несу в первую очередь я. передо мной несут ответственность руководители проектов. А если мне руководитель проекта придет и скажет, что проект сфейлился, потому что Вася уже три месяца не делает вовремя порученные ему задачи. То надо уволить этого менеджера, т.к. он не решил проблему за 3 месяца, ну и следом меня, т.к. о том что на проекте 3 месяца идет отставание по срокам я узнал в день релиза.marshinov
12.01.2017 17:26+1Давайте так: отвечать должны и те и другие в рамках своих полномочий и прямых обязанностей. И закроем тему:)
Teacher
13.01.2017 11:12+1Именно, каждый должен отвечать за свою часть общего дела. В пьесе представлены менеджеры типа «передасты». Которые кроме как передавать от руководства хотелки на разработчика, а оценки разработчика руководству — ничего не могут. А в случае проблем или ответственности пытаются их спихнуть на других.
Neikist
12.01.2017 23:44+2Интересно, как разработчику запретить дергать себя другим людям? Вот посадило начальство 10-15 человек половина которых программисты, а вторая аналитики и менеджеры в один кабинет, и крутись как хочешь. В результате задачи на 30-40 минут растягиваются на все 8ч, из которых 6 часов тебя дергают разные люди с вопросами или левыми задачами (уточнить тп, рассказать как пользоваться фичей, нарисовать схему для заказчика, обсудить какие нибудь требования с заказчиком, подбежать с багом «ну тут же на 5 минут исправить, глянь по быстрому» и т.п.) и все это сопровождается постоянными телефонными звонками, гоготом, разговорами в стиле «а вокруг России одни враги, а Люба разошлась со своим то, а вот начальник из Москвы фотки из европы показывал», остальное время тратишь на вспоминание «а что же я там уже успел по задаче сделать» и на попытку внести задачи в систему тайм-трекинга. И потом еще виноват оказываешься что медленно работаешь, да еще и система тайм трекинга показывает дикие трудозатраты на получасовую задачу (не будешь же 5минутный разговор заносить, а требуется внести ровно 40 часов в неделю)
VolCh
13.01.2017 10:38Я часто менеджеру и топ-боссам говорю: «разрешите мне работать из дома, не читать почту, игнорировать все сообщения/звонки от коллег кроме ваших лично и я сделаю эту задачу за неделю, если сами же другие задачи поручать не будете. А так, оптимистичная оценка — месяц, средняя — два». Раза три прокатывало, один из них, правда, сказали работать в офисе партнеров.
marshinov
13.01.2017 12:06Ставьте себе график — 40 минут работаете, 20 — перерыв. Из них 10 — перекур/прогулка/чай/беседы на отвлеченные тем, 10 — преговоры с коллегами. Все не срочные вопросы перенести в текстовое общение и отвечать в асинхронном режиме. Довести до коллег свой распорядок. Во многих организациях такой распорядок закреплен руководством.
VolCh
12.01.2017 16:28-3В том-то и дело, что не отвечает в общем случае. Не должен отвечать. Он даёт прогноз, а не результаты спиритического сеанса. Вы же не считаете, что синоптики должны отвечать за результаты своих прогнозов? Или политические аналитики?
marshinov
12.01.2017 16:30+5Тогда руководитель не отвечает за своевременность выплаты заработной платы, а менеджер за сроки проектов. Они дают прогнозы и гадают на картах Таро.
VolCh
12.01.2017 16:38-2Руководитель отвечает за своевременность выплаты зарплаты. Вплоть до уголовной ответственности. А за что отвечает менеджер — это их договоренность с руководителем.
nicholas_k
12.01.2017 22:15Простите, что вмешиваюсь в ваш спор.
Мне кажется, что разработчики часто не отвечают за свои прогнозы.
Но иногда отвечают и таких разработчиков ставят сеньорами и тимлидами.VolCh
13.01.2017 12:46Тимлидами ставят тех, кто готов отвечать за всю команду, как ни странно. И тимлид — уже скорее менеджер, чем разработчик. Почему я и отбрыкиваюсь от попыток делать меня тимлидом. Сеньором, архитектором, техлидом — пожалуйста. Но отвечать за свои, а, тем более чужие, прогнозы и, тем более, косяки — увольте. Не увольняют почему-то.
mad_nazgul
13.01.2017 23:30Прошу прощения. Программисты не должны отвечать за сроки.
Они должны отвечать за код!
Точнее за качество кода.
Чтобы при добавлении новой фичи
1) Количество ошибок на фичу не увеличивалось
2) Время на добавление фичи не росло в экспоненциально.
Потому что «выигранное» X времени сейчас, выльются в e^X потом.nicholas_k
14.01.2017 21:11+2Поверьте на слово — идеальный код, законченный к моменту провала проекта — гораздо хуже, чем плохонький, но работающий и решающий чьи-то проблемы.
Кроме того — если программисты не отвечают за сроки, то откуда вообще их брать?
В предыдущих комментариях, да и в тексте поста есть определенное недовольство тем, что менеджеры высасывают сроки из пальца. По вашему получается, что это нормальная ситуация.VolCh
15.01.2017 00:13В большинстве случаев объективной привязки (кроме бюджета на разработку и подобных финансовых кейсов) к каким-то датам нет, просто нужно как можно скорее. И менеджменту сроки окончания разработки нужны для привязки других мероприятий типа резервирования рекламных мест, набора расширенного штата, аренда новых помещений и т. п. Или наоборот, подготовки к сокращению штата и т. д. Менеджмент любит параллельные процессы, чтобы к моменту готовности продукта его сразу запускать в эксплуатацию, не неся дополнительных расходов за слишком раннее проведение других мероприятий и не теряя потенциального дохода за время простоя продукта из-за их неосуществления.
khim
15.01.2017 01:35Ага. А потом менеджмент, который принимает слова программиста за чистую монету проводит массивную рекламную компанию в 1983м в то время как продукт выходит в 1985м. Собственно задача менеджера любой компании, которая что-то разрабатывает — научиться как-то с этим жить. И разработка нового сайта тут ничем не отличается от задачи разработки нового Boing'а: и там и там устраивать разработчикам разносы — лучший способ остаться с «разбитым копытом».
VolCh
16.01.2017 10:19Вот в том-то и дело, что это задача менеджера, это его обязанность учитывать риски ошибочности оценок разработчиков.
nicholas_k
12.01.2017 19:27+1Потому что определение подходящего срока — это ответственность менеджера. Программист — он код фигачит и о сроках имеет весьма приблизительное представление.
Надеюсь вы не имеете в виду, что сроки выполнения задач должны определять менеджеры вместо программистов?
VolCh
12.01.2017 16:23+1Потому что программист срок в который он уложится обычно не называет. Он даёт вероятностную оценку трудозатрат (или вообще абстрактные поинты, привязанные к сложности), по которой менеджер, пользуясь своими профессиональными знаниями, навыками и опыту, сообщает сроки руководству. Очень часто в форме обязательства. Если сроки сорваны, то это ответственность прежде всего менеджера — неправильно оценил риски. И, скорее всего, не заметил имеющиеся признаки срыва заранее. Или заметил, но толком ничего не предпринял.
Murat1992
12.01.2017 19:28+1Думаю, вина не может быть абсолютной, все зависит от того, кто кому обещал и кто обещание не выполнил.
Разработчик обещает менеджеру, менеджер обещает начальству.
Разработчик виноват перед менеджером, менеджер перед начальством.
Если разработчик начальству ничего не обещает, то он перед ней и не виноват.
Думаю мыслю поняли.VolCh
12.01.2017 19:56+2У менеджеров и начальства есть склонность принимать оценки, планы, прогнозы за обещания.
Murat1992
12.01.2017 22:53Это нормально. Они сделали ставку на то, что разрабы, могут притворить эти планы и прогнозы в жизнь. В худшем случае ставка не сыграет.
Разработчик виноват в неверной оценке.
Руководство — в том, что доверилось прогнозу(оценке).
Оправдания никому не нужны. Ситуация в которой менеджер «оправдывает» себя, тем что ему обещали подчиненные — яйца выйденного не стоит. Он просто не хочет признать свою вину.
Начальство должно наказать менеджера, менеджер — подчиненного.
Будет печально если все шишки посыпятся только на разработчика.Neikist
12.01.2017 23:49+1Интересно, в чем виноват разработчик если он оценил фичу в неделю, менеджер сказал ок, навесил еще 2 задачи по два дня, и в итоге спрашивает в конце недели почему ничего не готово?
Murat1992
13.01.2017 06:57Он должен был отказатся от этих 2 задач.
Ну, или отложить релиз фичи. В таком случае об этом надо доносить, тому кому эта фича была «обещана».Neikist
13.01.2017 07:19А в том и проблема что бесполезно это объяснять. Особенно когда над головой несколько менеджеров, каждый свою задачу приоритетной считает, и каждый, несмотря на то что прямо заявляешь что это названное время работы — не срок, а именно время работы над задачей, будет ожидать результата через время названное разработчиком. Ну и отказаться возможности нет (даже временно), принцип: я начальник — ты дурак.
VolCh
13.01.2017 12:51+2Проблема даже не в том, что они ожидают через это время, а в том, что они ожидают, в лучшем случае, через это время по рабочему графику, а не по времени, затраченному на их задачу.
BlackFlyingCat
12.01.2017 13:49+1Хороший менеджер — это тимлид. И как раз ответственность тимлида оценивать сроки.
В случае же когда разговаривают менеджер и разработчик проблема не в менеджере и не в разработчике а в человеке, который поставил их разговаривать друг с другом.
Тимлид — человек вышедший из разработки, как правило половину времени уделяет распределению задач, написанию ТЗ, донесением до менеджеров и руководства всей сути технической работы)BlackFlyingCat
12.01.2017 13:54+1Когда-то я был малым и глупым и работал в компании где директор разговаривал напрямую с разработчиком(мной, при этом еще студентом). Тогда разработчик сдуру согласился писать новый проект за пару недель, как очень хотело руководство. Удивительно, но проект не был закончен вовремя и разработчику предложили поработать еще в режиме 18 часов кодинга в день 7 дней в неделю. После этого последовало очень неожиданно для директора последовало ПСЖ.
Так что да, в компаниях где нет тимлида самое разумное действие разработчика — писать ПСЖ. А еще лучше даже не пытаться устраиваться в такую компанию.
P.S. После этого наняли тимлида и переписали и старый и новый проекты с Явы на C++. Потому что новый тимлид не знал Яву) И это все равно было лучше, чем без тимлида.BlackFlyingCat
12.01.2017 13:59+2P.P.S Менеджер в компании тоже был и пытался решить провал сроков путем введения мегаплана(не джиры, не гита — мегаплана) и отчетности. После этого разработчик даже на диалог не захотел идти)
Wesha
13.01.2017 05:03хороший считает (и не в глубине души, а публично заявляет), что это его ошибка, что он оценку разработчиков выдал за свое обязательство.
Правило Вестгеймера Чтобы определить, сколько времени потребует работа, возьмите время которое, по-вашему на нее необходимо, множьте на 2 и замените единицы измерения на единицы более высокого порядка. Так, мы выделяем два дня на одночасовую работу.
chieftain_yu
13.01.2017 09:26О, если бы менеджеры четко следовали этому правилу, называть время стоило бы с миллисекундах.
Там разрыв с единицей времени более высокого порядка посолидней будет, чем по другим вариантам.
SerCe
14.01.2017 05:49Обычно программисты имеют низкий социальные навыки
Сморозили чушь, наделали ошибок, да еще и полхабра оскорбили. Nice work!
am0rall
18.01.2017 02:04-1Вы либо толстый зеленый тролль, либо феерический долбоеб.
Простите меня за мой французский, но я безмерно возмущен!
dmitry_ch
11.01.2017 19:55+6Надо что-то делать с текстом, а то слово «говно» в нем уже стало техническим долгом. То «гавно», то «говно» — вы уж на гОвно замените везде.
Или это как пример технического же долга?DemetrNieA
11.01.2017 20:15+5Как пример технического долга я вставил off by one error в нумерации частей. Спасибо что заметили.
dmitry_ch
12.01.2017 11:11+2Спасибо за момент, когда пол-ежа заливают сверху говном. Это — самое жизненное.
Реальный случай с совещания, когда топ-менеджмент предлагал разрабу, чтобы старый 16-битный код запустить в 32-битном окружении, просто забить нулями вторую половину каждого 32-битного слова. И это, замечу, было техническое руководство, которое увидело способ быстро интегрировать старый, совсем доисторический, код с более новым, просто доисторическим.
Разраб, когда после совещания отошел немного, пошел и написал «по собственному».
Deosis
13.01.2017 07:59+1Нужно было внести встречное предложение:
Менеджер, получавший 70 тысяч, буде получать 4464. Чтобы не ругались на ошибки переполнения.
solver
11.01.2017 20:28+3> система КРОТОПОН, которая работает на продакшане заглючила и мы потеряли кучу денег.
Так и не смог разгадать ребус и вычислить название реальной системы(
Поделитесь? )Demogor
12.01.2017 01:10+4Видимо это гибрид крота и пони — слепой, слабый, полон рюшечек и работает только когда его никто не видит.
dmitry_ch
12.01.2017 12:02+1Сначала подумал, что это аллюзия на
Страпони
SbWereWolf
11.01.2017 21:28+1спасибо, у меня сейчас такой сценарий разыгрывается :) уже второй менеджер :))
maniacscientist
11.01.2017 21:38+6Всё верно, кроме последнего абзаца. Компания не разоряется, продукт-то работает. Ну и пофиг что костыли, ынтырпрайз же. Продукт продают, для поддержки достаточно макак. Опять же на премии и повышении сэкономили.
Так оно и задумывается на борде, ваще та. А готового выгореть разраба можно и нового найти.
ArRnorets
11.01.2017 22:40+6Довольно поучительно и наглядно для демонстрации того, к чему приводит длительное забивание на технический долг. Однако, довольно сильно идеализировано, и менеджер все-таки чересчур демонизирован( хотя, в этой конкретно ситуации он реально самодур). Все это похоже на разработку какого-то внутреннего продукта больше для нужд самой компании. А давайте представим, что где-то в антракте между третьей и четвертой частью ( наиболее подходящее место, как мне кажется ), на сцену врывается Конкурент (К), и начинает неистово рекламировать свой ( как потом окажется, не совсем еще стабильный, но пофигу — главное, сейчас нишу захватить и пользователя подсадить. И пофигу, что костыли — они же у нас армированные(!), потом заменим ) продукт, да еще со скидкой, да еще с бесплатным тестовым периодом. В результате, начиная с 4-й части, менеджер будет где-то вынужден идти на «непопулярные» меры, в противном случае проект ( а может, и компания ) рискуют не дожить до концовки пьесы, ибо продукт-то хорош, а толку-то с него, аудитория уже захвачена и накрепко подсажена на продукт К, а ресурсов ждать, пока пользователь осознает, какие вы крутые, и продвигать эту свою крутость в массы, попросту нет. Ввиду пока еще высокой динамики развития отрасли ИТ такой сценарий видится гораздо более реальным, да и практика показывает то же самое.
Идеальный управленец вообще не должен иметь конфликт интересов со своими разработчиками. Наоборот, он должен быть арбитром между конечным заказчиком/пользователем и своей командой. Но это в идеале. А так то, что довольно часто проект становится жертвой субъективизма менеджмента, тут вы правы, ничего не поделаешь…
Shamov
12.01.2017 14:51-5Вообще говоря, пьесы не так пишутся. В пьесе у персонажей есть имена и фамилии, а их роли и характеры раскрываются в результате взаимодействия и диалогов в различных ситуациях. Читатель не должен сразу знать, кто есть кто, а должен сам распознать это по ходу пьесы. В этом вся соль. Без этого пьеса — не пьеса...
jetexe
12.01.2017 14:53+3не всегда. Частенько в объявлении персонажей присутствует и краткое описание
f0rk
12.01.2017 18:02+1У меня немного другая история была, как-то 1.5 года оттимлидил на проекте где 3 ПМа сменилось, причем не с повышением, а с увольнением ПСЖ. Ситуацию они особо не контролировали, но служили неплохим буфером между заказчиком и командой разработки. Когда случались факапы (а случались они постоянно :)), они самоотверженно получали люлей, потому наверное и не выдерживали подолгу… Ну а в целом проект закончился успешно, стал хорошим пунктом в моем CV, и я благодарен этим ребятам за то что спасали мою нервную систему.
skyle7
12.01.2017 19:28Это хороший пример что будет, если понимать все буквально, биться головой в стену и считать работой программиста написание кода, сверяясь с книжкой «Идеальный код» МакКонела.
В компании есть деньги, менеджер, СЕО и випы заинтересованы чтобы проект был принят. Этого достаточно чтобы где-то сделать по-своему, где-то сорвать сроки, где-то скорректировать требования, кого-то мягко проигнорировать, но сделать что-то работающее, что будет принято и будет развиваться дальше и может и будет кривое, но работающее и даже приносящее прибыль компании. Получить соответственно повышение зп и бонус.
Просто надо быть хитрее.Neikist
12.01.2017 23:55А потом «это» десяток лет развивать и поддерживать, плюс под каждый проект чуть ли не с нуля переписывать, потому что модифицировать «это» в адекватные сроки и без миллиона ошибок нереально.
skyle7
16.01.2017 12:58Тут надо понимать, что вы хотите
а) писать очень «правильный» софт с грамотными: ТЗ, архитектурой, выбранными технологиями, процессами разработки и деплоя, покрытиями тестами и современными стандартами по написанию самого кода.
б) долго работать программистом в крупной компании с повышениями и ростом ЗП.
Действия в статье описаны для человека, который хочет исключительно пункт А.
Можно для себя выбрать Б, а из «а» брать по возможности.
«А потом «это» десяток лет развивать и поддерживать» — ответил ниже.
chieftain_yu
13.01.2017 09:34Угу.
Не реализовать в системе часть функциональности, поставив имитатор.
А когда к клиенту нагрянет регулятор и натянет его по всей строгости (а то и посадит кого из его работников) — сделать честный вид и сказать «но ведь вы нам акты подписали», да.
Или для скорости наворотить неописанных костылей, а когда костылестроитель покинет компанию — задуматься, а как все это безобразие поддерживать. И кем.skyle7
16.01.2017 12:46Из-за вашего кода посадят кого-то в компании заказчика? Ерунда какая-то.
Neikist: «А потом «это» десяток лет развивать и поддерживать, плюс под каждый проект чуть ли не с нуля переписывать» зачастую это может быть и неплохо.
Надо смотреть что это за система, если это управление аппаратом по лазерной коррекции зрения- там я бы так делать не стал.
А если скажем… какой-нить документооборот в крупной компании- именно так как вы описали оно и делается в 90% не-айтишных компаний, например в строительной или нефтедобывающей. Эти все велосипеды на костылях потом надо поддерживать и дописывать- штат сотрудников увеличивается, а это означает повышение, рост зарплат.chieftain_yu
16.01.2017 13:57Ну скажем так — при фактической нереализации одной фичи посадить могут некоего невиновного человека (если, конечно, неработоспособность фичи не будет вскрыта).
Например, произойдет утечка данных с меткой этого человека, хотя по факту он будет непричастен.
Повышение и рост зарплат это означает в тучные годы.
А когда основной клиент-кормилец начинает вместо договоров предлагать держаться и желать всего доброго, хорошего настроения и здоровья — вот тут и начинаются основные проблемы с поддержкой как остальных пользователей этого продукта, так и пожелавшего сэкономить на поддержке основного.
И наиболее толковые сотрудники начинают искать счастья на стороне. Что еще больше усугубляет непонимание, как оно работает.skyle7
16.01.2017 16:51Это какой-то экстремальный случай- с посадкой. 95% софта все-так не несет серьезных последствий в случае уязвимостей/багов/недоработок. И отделен от программиста несколькими слоями- тестирование, приемка, проверка на уязвимости, поддержка на лайве.
Попробую еще другими словами дополнить свою мысль.
Разработчик — это не тот, кто отвечает за проект. Описанный в статье разработчик переживает насчет вещей, которые вообще не находятся в его компетенции. Он не знает, на каких исходных данных принимались решения выше, может это политические игры руководства и через 2 года этот продукт вообще не будет нужен. А может нужен, но они ошиблись в решениях. Но ошиблись то — они, а не разработчик.
Это как сборщик айфонов в Китае будет переживать — а как же таким телефоном будут пользоваться люди, неудобно ведь и неоправданно дорого! А через год все их повыкидывают и будут покупать новые! А старые станут такими медленными на новой оси. И уволится из-за этого, хотя предлагали нормальную зп.chieftain_yu
17.01.2017 09:02А.
Я понял ваш первый комментарий как «менеджер сказал запилить фичу в нереальные сроки, сделаю ему имитацию чтобы приемочные прошло, а там — не моя проблема».skyle7
17.01.2017 11:37+1А, тогда понятен ваш комментарий :)
Да, я имел ввиду «менеджер сказал запилить фичу в нереальные сроки, сделаю что-то работающее, но не все. А как он объяснит начальству что успели сделать не все — не моя проблема».
Еще дополню свою мысль :)
М: смог вытащить этот проект за такой малый срок. Так что меня повысили
М2: Какие мы молодцы… я вместе с Гуру перевожусь в другой отдел
«и решают сделать новую систему» — под руководством М3, видимо.
Т.е. М, М2, М3 и Гуру- в шоколаде (4 чел).
А разработчик: в какашках (1 чел)
И это все по результатам работы над одним и тем же проектом! Ну и кто из этих 5ти людей некомпетентный дуралей? :)
«Так и сказали, что я мастер управлением персоналом, что смог вытащить этот проект за такой малый срок. Так что меня повысили». Вот на этом моменте разрабу надо было ультимативно получать повышение, либо уходить с повышением зп. А когда дошло бы до «решают сделать новую систему» — получить еще 2 разраба и еще одно повышение.
xmaster83
12.01.2017 19:29Вот у знакомых команда без менеджера, с самыми высокими показателями в компании.
dev_marshak
14.01.2017 08:37Если это не OpenSource проект, думаю, все же менеджер есть, только его роль выполняет один из разработчиков, вероятно Senior.
Без человека координирующего команду, маловероятно, что, что-то коммерческое получится. Иначе не было бы уже давно такой профессии как «Менеджер».
Zezst
14.01.2017 04:53DemetrNieA А вы у нас кем работаете? Что то не признал по профилю.
</sarcasm_mode>
yurikgl
16.01.2017 10:11Хм… я видел обратную картину:
М: мне бы тут отчет сделать небольшой, пару SQL-запросов в Excel выкинуть…
Р: ну это на неделю работы… и премию надо… и ТЗ точное… а еще надо библиотеку изучить для формирования Excel-файла…
М: Мне завтра надо. И вообще это — однократная работа. Выгрузи уж как нибудь вот эти и вот эти столбцы.
Р: ну мне некогда ерундой заниматься и пишет служебку на 3 страницы, почему это сделать нельзя
М с боем выбивает доступ на чтение к СУБД у админов, остается вечерком, ваяет запросы и копипастит их в Excel…
Задача выполнена.
По мотивам реальных событий, рассказанных одним экономистом (собственно он и был М) в одной большой компании.VolCh
16.01.2017 10:26+3Совсем не обратная. Экономист пытался заставить разработчика заниматься не разработкой, а работой с данными. разработчик же, как ни странно, должен разрабатывать, а не данные кому-то выгружать.Слышим «выгрузи как-нибудь в Excel», понимаем: «разработать модуль выгрузки в Excel»/ Как поставлена задача, так и оценки времени разработки и даются. Мог бы поставить задачу: «напиши мне SQL-запросы, которые делают вот такую выборку» и оценка была бы другой.
yurikgl
16.01.2017 20:50Хм… и куда экономист должен воткнуть эти SQL-запросы?
Собственно, если бы экономист не вытягивал, то компания теряла бы неслабые деньги.
Странно что у программиста в этом случае нашлось время на написание служебки на 3 страницы )
p.s. что в истории совпадает, так это то, что премию дали экономисту )arheops
16.01.2017 23:15+4А не суть куда воткнут эти запросы. Разработчику поставлена задача, которая не является задачей для разработчика. А именно взять данные из таблички и скопипастить в ексель. Вполне нормально, что разработчик всеми силами от нее избавляется, поскольку иначе будет поставлена вторая такая же задача завтра, и разработчик превратится в секретаря(accounter на английском).
poxu
17.01.2017 08:59Разработчику поставлена задача, которая не является задачей для разработчика.
Ну вот у бизнеса возникла задача — отдать клиенту в экселе какие-то данные. Сделать надо завтра. Кому, кроме разработчика, можно поручить такую задачу?
Murat1992
17.01.2017 11:44+1Вина «бизнеса», раз не определили заранее, кто должен этим заниматься.
По хорошему разработчика не должны к данным вообще подпускать.poxu
17.01.2017 13:32У бизнеса все определено. Схему данных понимает только разработчик, поэтому запрос будет писать он. Выполнять запрос будет не он, а тот, кто имеет право на доступ к данным.
arheops
17.01.2017 22:07А вот и нет. Перечитайте постановку задачи и решение. Очевидно, что схему как минимум понимает менеджер и способен сам получить нужные данные и уж отчет то — точно его часть.
poxu
18.01.2017 12:35+1Постановка задачи — сделать пару sql запросов для отчёта.
Тот факт, что менеджер понимает схему свидетельствует о том, что разработчику попался технически грамотный менеджер, а не о том, что менеджер обязан понимать схему данных. Для этого есть разработчики.
Тот факт, что менеджер смог получить данные — чудо. В нормальной ситуации отказ разработчика делать запрос означает, что клиент не получит того, что ему было нужно.khim
18.01.2017 17:09Тот факт, что менеджер смог получить данные — чудо.
Почему же чудо? Обычное раздолбайство.
В мелких компаниях такое часто случается, но если бы подобная история про Amazon или Google попала бы в прессу — то иск на много миллионов был бы неизбежен.DemetrNieA
18.01.2017 21:23но если бы подобная история про Amazon или Google попала бы в прессу — то иск на много миллионов был бы неизбежен.
Что Вас заставляет так думать?khim
18.01.2017 23:46И вы вот это, например, вспомните.
А там даже не доступ какого-то левого менеджера к пользовательстким данным, а просто — сбор «сырах» данных, к которым особо-то и доступа ни у кого не было.
Так что то, что «экономист из одной большой компании» это провернул и не попался — это круто. А вот только рассказывать про нарушение трудовой дисциплины и, тем более, выдавать это за доблесть — не стоит.DemetrNieA
19.01.2017 00:31Собрать лишние данные — это не тоже самое, что построить отчёт по уже имеющимся. Думаю оный экономист имел все права на данные к тому же.
Но направление мысли я понял, спасибо.khim
19.01.2017 03:02Думаю оный экономист имел все права на данные к тому же.
Я вот — ни разу не уверен. Более того, уверен на 99%, что он этих прав не имел.
То есть понятно, что ему нужны были агрегированные данные, по которым можно было бы построить какие-то тренды. Но судя по описанию — доступ-то он получил к «сырым» данным. То есть, например, мог узнать кто, когда и чего купил в этой фирме. А дальше мы налетаем прямиком на разнообразные законы о персональных данных и получаем повестку в суд.
После чего «ТЗ точное» и «неделя работы» вдруг оказываются вовсе не таким уж непостижимо ужасным требованием…
VolCh
17.01.2017 18:39Экономистам, аналитикам, да хоть админам, а они должны часть "разработать SQL-запрос" задачи «отдать клиенту в экселе какие-то данные» делегировать разработчику.
DarkOrion
17.01.2017 21:18+1Разработчику поставлена задача, которая не является задачей для разработчика.
Собирать требования не задача разработчика, писать ТЗ не задача разработчика, писать SQL-запросы не задача разработчика, тестировать не задача разработчика, сдавать систему не задача разработчика…
Через сколько итераций перебора задач мы поймем, что на IT-проекте в нет задач для разработчика?VolCh
18.01.2017 19:02Писать SQL-запросы — задача разработчика. Выгружать результаты их работы — нет. Если бизнесу нужен какой-то отчёт по РСУБД в каком-то неподдерживаемом сейчас системой формате, то задача разработчика написать запрос, выбирающий данные из базы, написать модуль выгрузки в этот формат, написать UI для этого отчёта. Не нужны модуль выгрузки и UI, бизнес довольствуется SQL-запросами (как у нас, например, аналитики) — задача разработчика написать запрос. Желательно протестировать, возможно на боевой базе с чутким мониторингом нагрузки — вдруг он операционную деятельность положит. Но вот как-то из консоли или IDE выгружать результат запроса в Excel — не его задача.
kuznetsovin
19.01.2017 09:35Окей. Если никакие UI, модули и т.д. не нужны, надо просто выгрузить данные за определенный период, например по продажам, в Excel (тем более это можно сделать через источники данных, куда этот запрос можно воткнуть и забыть), кто этим должен заниматься программист или менеджер?
VolCh
19.01.2017 11:34Программист пишет SQL-запросы, передаёт их менеджеру, менеджер втыкает их в свой Excel. Если слабо разбирается в этом, то техподдержка/админы должны втыкать, тем более что права менеджеру может потребоваться давать, что программист точно делать не должен даже если у него есть рутовые.
Чисто в теории, программист, после разработки запросов, если у него есть права для выполнения этого запроса на боевой базе, если у него есть Excel, если он знает как результат запроса можно получить в Excel (я вот не знаю, последний раз с Excel работал в прошлом тысячелетии и то проверял как он открывает CSV файлы, которое выгружало моё приложение — тогда плохо открывал) может приложить результат запроса по текущим данным как образец результатов запросов, но это будет:
а) жестом доброй воли
б) риском получить «уточнение требований» типа «отрицательные значения выделить жирным красным, посчитать общие итоги и подитоги по месяцам, причём ячейка „месяц“ должна должен быть объединением для всех строк месяца, а не повторяться каждый раз, а подитог быть первой строкой»
в) риском постоянно получать подобные задачи, причём не только от данного конкретного менеджера, не смотря на обещания менеджера «первый и последний раз и никому не скажу»
г) уменьшением времени на исполнение своих прямых должностных обязанностей, что приведёт к увеличению календарных сроков окончания нормальных задач по разработке и, возможно, срыву дедлайнов. В лучшем случае — к неуменьшению технического долга, если открытых задач нет и обычно в свободное время что-то рефакторится. В самом лучшем случае — к замедлению профессионального роста: вместо того, чтобы новый фреймворк как инструмент решения прикладных задач пользователей софта изучать, программист будет Windows и Excel изучать как инструмент для решения своих прикладных задач
Zezst
16.01.2017 12:38+8М: Мне завтра надо. И вообще это — однократная работа. Выгрузи уж как нибудь вот эти и вот эти столбцы.
Вот такая однократная работа очень часто превращается в – «а помнишь ты мне выгрузку делал, надо повторить. Только …».
sompylasar
18.01.2017 20:21Уважаемый автор, а есть ли перевод сего великолепного произведения на английский язык? Хотелось бы поделиться.
DemetrNieA
18.01.2017 22:29+2Нет, история только написана. Думаю для перевода на английский стоит чуть-чуть подправить специфику.
kenrube
Спасибо, давно так не рыдал