Comments 196
Спасибо, давно так не рыдал
Как-то вы излишне демонизируете менеджеров, будто они совсем не заинтересованы в успехе проекта.
Обычно, если менеджер принимает неверное решение, это значит, что программист не смог донести всю тяжесть последствий. Обычно программисты имеют низкий социальные навыки, так что нужен специальный человек, для донесения до начальства мыслей о технической составляющей проекта.
Таких людей часто выделяют всякие оутсорсерские и облачные конторы. Они приезжают к начальству и рассказывают душераздирающие истории о том, что может пойти не так, с графикам и таблицами, как положено, и убеждают менеджеров больше тратить на IT.
Обычно, если менеджер принимает неверное решение, это значит, что программист не смог донести всю тяжесть последствий. Обычно программисты имеют низкий социальные навыки, так что нужен специальный человек, для донесения до начальства мыслей о технической составляющей проекта.
Таких людей часто выделяют всякие оутсорсерские и облачные конторы. Они приезжают к начальству и рассказывают душераздирающие истории о том, что может пойти не так, с графикам и таблицами, как положено, и убеждают менеджеров больше тратить на IT.
Обычно, если менеджер принимает неверное решение, это значит, что программист не смог донести всю тяжесть последствий.
— Аааа, у нас на проекте все очень плохо, почему ты не предупредил что так может быть?
— Но я же говорил что будет плохо если не сделать то и то…
— Да, но ты не говорил что будет ОЧЕНЬ плохо. Ты не старался до меня донести! Ты во всем виноват!
Ну надо понимать, с кем ты разговариваешь. Что для тебя очевидно, для него может быть нет. Он небось и считать умеет только до десяти, и математику последний раз видел в 9ом классе.
Он небось и считать умеет только до десяти, и математику последний раз видел в 9ом классе.Тогда почему он считает что он может решать, что нужно делать, а не я? И почему он вообще принимает какие-либо решения, если я должен до него «доносить» какие от них могут быть последствия?
Потому что он умеет и не боится взаимодействовать с неидеальным внешним миром и ориентироваться на результат.
Потому что даже когда хорошие друзья хотят вместе выбраться на пикник, должен найтись хотя бы один человек, который будет всех непрерывно пинать и напоминать об их желаниях, координировать планы.
Потому что даже когда хорошие друзья хотят вместе выбраться на пикник, должен найтись хотя бы один человек, который будет всех непрерывно пинать и напоминать об их желаниях, координировать планы.
Ты наверное М3 из рассказа.
Справедливости ради стоит отметить, что бывают (редко) менеджеры, вышедшие из разработчиков: это типа как мульти-класс в AD&D: качаешься до 10 lvl «Разработчиком», а потом получаешь новый класс и снова до 10 с нуля: долго, сложно, зато в конце получается не специалист, а конфетка. Времени на это правда уходит вагон и маленькая тележка.
Очень много историй, как разработчики уходят в менеджеры, считая это развитием, а в итоге оказываются жестко ограничены окружающими условиями и перестают развиваться. За это время выходит тысяча новых фреймворков, меняются тренды и ценность этого человека как программиста безнадежно падает (причем наверняка не объективно, а лишь в глазах М1-М3).
Все самые «жесткие ограничения» у человека в голове.
Даже если разработчик «устаревает» — он всё равно лучший менеджер потому что он более в теме, чем просто чистый манагер. Тупо потому, что он понимает, что вот взять вот этот кусок говна с костылями и «прикрутить к нему фигулинку» — это не «5 минут… ну максимум час, что тебе сложно что ли? Мы же так уже делали в проекте ААА, а здесь — точно так же». Он знает, что «точно так же» — нифига не так же, знает, что из процесса разработки — нельзя выкинуть «неважные детали» типа тестирования. И ещё много разных «он знает, что ...».
так они уходят за разитием себя в смысле карьеры или личных целей, а не в смысле развиваться как «еще более лучший»™ программист.
поддерживать ценность себя как программиста после перехода в менеджмент это нерациональное использование ресурсов.
поддерживать ценность себя как программиста после перехода в менеджмент это нерациональное использование ресурсов.
Вы не совсем верно меня поняли. Я говорил именно о том, что разработчик уходит в менеджеры ради карьерного роста и личных целей, пологая что завис в пространстве, работая разработчиком. И в итоге попадает в комнату со стеклянным потолком: его вроде как и не видно, но он очень сильно ощущается. После этого он понимает, что пути развития в роли разработчика у него были, а в роли менеджера он действительно не может двигаться дальше. Я не утверждаю, что это верно для всех ситуаций, а всего лишь говорю, что такое происходит и даже не раз было описано на хабре/гиктаймс.
поддерживать ценность себя как программиста после перехода в менеджмент это нерациональное использование ресурсов.
Как показывает хотя бы этот топик, менеджер с актуальными навыками программирования и всего вокруг него более востребован программистами как начальник (product owner в SCRUM). Субъективно, у такого менеджера доля успешных проектов и удачных спринтов будет выше.
более востребован программистами как начальник
ну тут наверное важнее востребованность у бизнеса, а не у программистов, поскольку это бизнес платит в конце то концов.
да и актуальность навыков изчезнет за полгода-год.
но да, программистам наверное будет приятнее, мол «свой человек когда-то был».
хотя может и наоборот «вроде свой человек, должен понимать, а он!!»
(SCRUM product owner — это не менеджер все же)
в любом случае, переход раработчик-менеджер это не развитие карьеры разрботчика, это фундаментальное изменение, и жаль когда разработчики в попытках развить карьеру этого не понимают.
Программисты разбегутся и бизнесу и начальник не нужен будет. То есть востребованность программистами определяет и востребованность бизнесом. Не обязательно это ключевой фактор, но важный.
(Как не менеджер, если принимает бизнес-решения по распределению ограниченных ресурсов?)
Тут зависит от того, что считать разработкой. Например, вот начал я работать один над проектом (веб-приложение в интранет), начал зарываться со временем — с одной стороны обычный поток задач, связанных с развитием бизнеса, с изменением законодательства и т. п., с другой — хотелки стейкхолдеров, которые наконец-то получили человека, который успешно их реализует. Анализ ситуации показал, что много времени уходит на рутинные задачи по фронтенду, взяли мне в помощь фронтендера. Я ставлю ему чёткие задачи с указанием необходимого мне пути решения, вплоть до ссылок на библиотеки, которые надо использовать, он их выполняет. Можно ли сказать, что я перестал заниматься разработкой фронтенда? Код писать перестал почти, а вот разработкой, по-моему, не перестал заниматься. С другой стороны, можно ли сказать, что я стал менеджером? Как по мне, то стал. Я делегирую ему решение своих подзадач, ставлю приоритеты, контролирую прогресс и качество, отвечаю по сути за результат его работы. Чем не менеджер?
(Как не менеджер, если принимает бизнес-решения по распределению ограниченных ресурсов?)
Тут зависит от того, что считать разработкой. Например, вот начал я работать один над проектом (веб-приложение в интранет), начал зарываться со временем — с одной стороны обычный поток задач, связанных с развитием бизнеса, с изменением законодательства и т. п., с другой — хотелки стейкхолдеров, которые наконец-то получили человека, который успешно их реализует. Анализ ситуации показал, что много времени уходит на рутинные задачи по фронтенду, взяли мне в помощь фронтендера. Я ставлю ему чёткие задачи с указанием необходимого мне пути решения, вплоть до ссылок на библиотеки, которые надо использовать, он их выполняет. Можно ли сказать, что я перестал заниматься разработкой фронтенда? Код писать перестал почти, а вот разработкой, по-моему, не перестал заниматься. С другой стороны, можно ли сказать, что я стал менеджером? Как по мне, то стал. Я делегирую ему решение своих подзадач, ставлю приоритеты, контролирую прогресс и качество, отвечаю по сути за результат его работы. Чем не менеджер?
Это называется Dual Class а мультикласс это когда развивается сразу во всех направлениях.
Только это называется дуалкласс ;-)
И, кстати, требования к дуалклассу заметно выше, чем к каждому классу по отдельности. Грубо говоря, файтеру, дуалящемуся в мага, нужно не только иметь достаточную силу, но и заметно бОльший, чем обычному магу, интеллект.
Смею полагать, что дуалклассу "разработчик->менеджер" тоже нужны повышенные требования и к интеллекту, и к харизме.
Потому что он умеет и не боится взаимодействовать с неидеальным внешним миром и ориентироваться на результат.
Это такая идеальная отмазка, чтобы скрыть некомпетентность руководства?
Если у тебя есть все необходимые компетенции, то почему ты сам не пошёл в руководство? Программистам не нравится работать менеджерами, применять необходимые для этого навыки. Вот к ним и приходит менеджер со стороны, чтобы заполнить вакансию. Может он вообще программы не выпускал, а дороги катал или катком заведовал. Он имеет все необходимые знания для менеджера, но не имеет опыта в конкретной предметной области.
Если у тебя есть все необходимые компетенции, то почему ты сам не пошёл в руководство?
Не нравится.
Ну пусть катает дороги дальше.
Или в нашей удивительной стране кухарки могут управлять не только государством, но и высокотехнологичным производственным процессом?
PS: У меня нет необходимых компетенций, чтобы быть в руководстве, у меня есть компетенция в области разработки ПО. Потому и не иду.
Или в нашей удивительной стране кухарки могут управлять не только государством, но и высокотехнологичным производственным процессом?
PS: У меня нет необходимых компетенций, чтобы быть в руководстве, у меня есть компетенция в области разработки ПО. Потому и не иду.
А что в вашей удивительной стране программисты после выпуска из вуза знают сразу 100500 языков и фреймворков, каждую предметную область, от вебсайтов до микроконтроллеров, от игрушек до геораспределённых систем? Могут использовать любую известную базу данных или изготовить свою?
Нет. Так зачем же требовать от менеджеров всезнания? Помогайте ему по мере ваших сил, у вас один проект и одна цель!
Нет. Так зачем же требовать от менеджеров всезнания? Помогайте ему по мере ваших сил, у вас один проект и одна цель!
Как-то Вы лихо с больной головы на здоровую. Задело, что ли? Не хотел, честно.
Я же не требую всезнания от менеджеров, я требую компетенции в заявленной области. Думаете, я не видел программистов, которые заявляли больше, чем умели?
Я же не требую всезнания от менеджеров, я требую компетенции в заявленной области. Думаете, я не видел программистов, которые заявляли больше, чем умели?
Вы сравниваете менеджера, который пришел с укладки дорог, и программиста, которіе не знает все фреймворки? Это, по-вашему, хорошая параллель?
Ну а что, сейчас менеджеры прям при выходе из менеджерских ВУЗов в курсе как работают кодеры в IT? Они же не знают, где ещё будут применяться их знания, основной их навык — это «программирование» людей. А на какую задачу их нужно будет программировать, наперёд не известно.
Точно так же как выпускнику прогерского ВУЗа не известно, какой ему придётся JS движок использовать в работе. Научится по дороге.
Точно так же как выпускнику прогерского ВУЗа не известно, какой ему придётся JS движок использовать в работе. Научится по дороге.
Они же не знают, где ещё будут применяться их знания, основной их навык — это «программирование» людей. А на какую задачу их нужно будет программировать, наперёд не известно.
Ну вот, собственно, этим всё сказано. Приходит такой менеджер на производство и начинает наносить непоправимую пользу. Если команда хорошая — он не сильно много пользы нанесёт, если не такая хорошая, то у конторы сразу проблемы.
Всё из-за подхода — я программирую людей, зачем мне знания в области, в которой я руковожу.
У менеджеров, на минутку, тоже есть специализации типа «управление машиностроительным производством», где как раз таки понимание особенностей работы и организации работ в данной отрасли очень важно. Без этого понимания и будет получаться что «Возьмем 9 беременных женщин и родим ребенка за месяц. Ну а чо, я ж не биолог.»
Проект, может, и один, а вот цели не совсем одни. На многих проектах менеджерам важнее сроки и большой список фич, чем пустой список багов.
В пьесе описан менеджер, который, не являясь компетентным, не слушает того, кто является компетентным. В этом-то и проблема.
От менеджера не требуется всезнание — от него требуется коммуникация не только с начальством, но и с подчинёнными. Только в этом случае это один проект и одна цель. А то, что описано в пьесе, больше похоже на «я начальник, ты дурак». Это не один проект и одна цель, это — спущенная сверху разнарядка, от реальности очень сильно оторванная.
Ты можешь не знать всего — и это нормально — но если проект для тебя значит больше, чем собственные амбиции, ты будешь слушать своих подчинённых и опираться на них, а не приказы начальства. Если же впереди амбиции, то получается ровно то, что описано в пьесе. И цена такому менеджеру — нуль. Вне зависимости от его знаний и опыта. Не надо искать оправданий очевидной некомпетентности.
От менеджера не требуется всезнание — от него требуется коммуникация не только с начальством, но и с подчинёнными. Только в этом случае это один проект и одна цель. А то, что описано в пьесе, больше похоже на «я начальник, ты дурак». Это не один проект и одна цель, это — спущенная сверху разнарядка, от реальности очень сильно оторванная.
Ты можешь не знать всего — и это нормально — но если проект для тебя значит больше, чем собственные амбиции, ты будешь слушать своих подчинённых и опираться на них, а не приказы начальства. Если же впереди амбиции, то получается ровно то, что описано в пьесе. И цена такому менеджеру — нуль. Вне зависимости от его знаний и опыта. Не надо искать оправданий очевидной некомпетентности.
> Он имеет все необходимые знания для менеджера, но не имеет опыта в конкретной предметной области.
Ну вот потому такого менеджера и не следовало бы брать в ИТ.
Ну вот потому такого менеджера и не следовало бы брать в ИТ.
Программистам не нравится работать менеджерами, применять необходимые для этого навыки.
Полагаю у вас однобокая статистика. Все менеджеры кроме одного с которыми я работал, будучи разработчиком, были либо бывшими либо действовавшими программистами. И проект знали или на уровне разработчика или на уровне администратора. И это опыт по трём компаниям и полудюжине менеджеров.
Работающие в таких компаниях обычно не пишут подобные статьи.
Речь идёт об «эффективных манагерах», которые, по сути применяют один и тот же алгоритм:
1. Корову меньше кормить и чаще доить.
2. Получить бонус на «эффективность».
3. Вовремя свалить (в идеале — на повышение).
Для этого, в сущности, знаний не нужно — достаточно звериного чутья. Потому что пунк #3 — ключевой.
Речь идёт об «эффективных манагерах», которые, по сути применяют один и тот же алгоритм:
1. Корову меньше кормить и чаще доить.
2. Получить бонус на «эффективность».
3. Вовремя свалить (в идеале — на повышение).
Для этого, в сущности, знаний не нужно — достаточно звериного чутья. Потому что пунк #3 — ключевой.
+1 немного поработал в нескольких стартапах из США (удаленно, но все же), возможно не все, но часть практикует «горизонтальную» структуру управления, когда тебе звонит по скайпу инвестор-менеджер проекта и он может не имеет обширной практики программирования на языке X, но прекрасно разбирается в терминологии и software development в целом и говорить с ним можно на техническом сленге, без всяких скидок — «ну он же не понимает». И как правило проекты под руководством таких менеджеров заканчиваются успешно, чего не скажешь о тех «менеджерах» которые лезут «руководить» в той области в которой не разбираются.
Он небось и считать умеет только до десяти, и математику последний раз видел в 9ом классе.
Менеджер. В айтишной конторе. Сириусли?
Что он в ней делает?
Пускай идёт вагоны разгружать, бестолочь.
С другой стороны, эта система уже может приносить деньги, которые полностью окупят дальнейшие затраты.
а потом момент упущен, рынок перенасыщен, затраты на маркетинг увеличиваются на порядок (а то и на несколько). И в конечном итоге выходит, что нафиг никому не нужен ваш чистовылезанный проект. Как бы самому не было противно, но таковы реалии
Они не заинтересованы в том, чтобы проект не провалился.
Это такая дилемма миддл менеджера: единственный способ быть замеченым и получить повышение — это когда проект удаётся и привлекает внимание высшего начальства (т.е. в сжатые сроки, приоритетное направление, и т.д.), а неудачи не приводят к плохим последствиям, т.к. можно размазать ответственность и вообще иногда неудачи — это даже хорошо, т.к. можно попросить больше денег и привлечь внимание к себе.
Такое состояние приводит к тому, что возникает конфликт интересов и им субъективно выгодно принимать рисковые решения.
Это такая дилемма миддл менеджера: единственный способ быть замеченым и получить повышение — это когда проект удаётся и привлекает внимание высшего начальства (т.е. в сжатые сроки, приоритетное направление, и т.д.), а неудачи не приводят к плохим последствиям, т.к. можно размазать ответственность и вообще иногда неудачи — это даже хорошо, т.к. можно попросить больше денег и привлечь внимание к себе.
Такое состояние приводит к тому, что возникает конфликт интересов и им субъективно выгодно принимать рисковые решения.
>Как-то вы излишне демонизируете менеджеров, будто они совсем не заинтересованы в успехе проекта.
Неа. На самом деле все еще хуже. Вот совершенно реальный разговор из жизни:
П: можно сделать вот так, и тогда мы релизимся через неделю, или вот так — и тогда релиза не будет через три месяца.
М: хорошо, делаем по варианту два, три месяца это вы пессимист, сделаем за два.
Проходит три месяца. Релиза нет, и непонятно когда будет.
Менеджеру не нужен успех проекта. Менеджеру не нужен качественный код. Ему нужно выбить деньги на проект, и потом их потратить, а в случае проблем — свалить вину на кого-то другого, и выбить денег на исправление проблем. Я не хочу сказать, что это всегда так — но увы, это достаточно типично.
P.S. Пока писал, появился комментарий выше. И я с ним согласен — конфликт интересов что-то слишком типичен.
Неа. На самом деле все еще хуже. Вот совершенно реальный разговор из жизни:
П: можно сделать вот так, и тогда мы релизимся через неделю, или вот так — и тогда релиза не будет через три месяца.
М: хорошо, делаем по варианту два, три месяца это вы пессимист, сделаем за два.
Проходит три месяца. Релиза нет, и непонятно когда будет.
Менеджеру не нужен успех проекта. Менеджеру не нужен качественный код. Ему нужно выбить деньги на проект, и потом их потратить, а в случае проблем — свалить вину на кого-то другого, и выбить денег на исправление проблем. Я не хочу сказать, что это всегда так — но увы, это достаточно типично.
P.S. Пока писал, появился комментарий выше. И я с ним согласен — конфликт интересов что-то слишком типичен.
Притча "Менеджер и программист"
Человек, летящий на воздушном шаре, обнаружил, что потерялся. Он спустился немного ниже и заметил на земле женщину. Спустившись ещё чуть ниже, он обратился к ней:
— Простите, не могли бы вы помочь? Я договорился с другом встретиться час назад, но не знаю, где сейчас нахожусь.
— Вы находитесь на воздушном шаре в 30 футах от поверхности Земли, между 40 и 41 градусом северной широты и между 59 и 60 градусом западной долготы ответила женщина.
— Вы, должно быть, программист?
— Да, а как вы догадались?
— Вы мне дали абсолютно точный ответ, но я совершено не представляю, что делать с этой информацией, и я всё ещё потерян. Откровенно
говоря, вы мне совершенно ничем не помогли.
— А вы, наверное, менеджер?
— Да. А вы как догадались?
— Вы не знаете, где находитесь и куда направляетесь. Поднялись вы туда, благодаря воздуху. Вы дали обещание, которое не представляете, как выполнять, и ожидаете, что люди, которые находятся ниже вас, решат ваши проблемы. И, наконец, сейчас вы в том же самом положении, в котором находились до встречи со мной, но почему-то теперь в этом оказалась виновата я.
Просто почему-то вспомнилось...
О боги, спасибо!
Через 20 лет я узнал, что у анекдота есть продолжение ("— А вы, наверное, менеджер?")
Через 20 лет я узнал, что у анекдота есть продолжение ("— А вы, наверное, менеджер?")
И это еще повезло посреди Атлантики программиста встретить.
> Поднялись вы туда, благодаря воздуху.
В английском оргинале «you got where you are thanks to a lot of hot air» — тут идиома, на русский в целом переводится как «вы оказались на своей высоте [(должности)] благодаря тому, что много заговаривали зубы/пудрили мозги», но в переводе на русский игра слов с «горячим воздухом» пропадает :(
В английском оргинале «you got where you are thanks to a lot of hot air» — тут идиома, на русский в целом переводится как «вы оказались на своей высоте [(должности)] благодаря тому, что много заговаривали зубы/пудрили мозги», но в переводе на русский игра слов с «горячим воздухом» пропадает :(
будто они совсем не заинтересованы в успехе проекта
Обычно менеджерам сообщается что-то вроде: эта фича займёт от 40 до 120 часов. Они докладывают наверх: будет готово через неделю, может 10 дней. И при этом постоянно подгружают мелкие задачки на час-два в день, ежедневные совещания на полчаса по фиче, пару совещаний по будущим задачам по часу. Какие ещё скилы нужны от разработчика, чтобы менеджер 120 разделил на, максимум, 6 часов и получил срок в месяц?
Так-же часто бывает обратное: менеджер закладывает 200 и все-равно не успевают
Бывает, да. Но в чём отличие хорошего менеджера от плохого — хороший считает (и не в глубине души, а публично заявляет), что это его ошибка, что он оценку разработчиков выдал за свое обязательство. Плохой же менеджер заявляет, что разработчики не выполнили свои обязательства, а он не причем, он лишь проинформировал руководство об обязательствах разработчиков, да ещё заложил риски, но разработчики всё равно не выполнили свои обязательства.
Спасибо, прекрасный критерий.
Вообще армейский критерий :) С другой стороны, офицер, командир подразделения — это тоже менеджер.
Это плохой критерий, потому что остальные члены команды не чувствуют никакой ответственности и причастности к результату.
А то, что они этого результата собственно и достигают — это не считается?
Результат достигается совместными усилиями команды: разработчиками, менеджерами, аналитиками, тестировщиками, дизайнерами, проектировщиками, ..., а не только программистами. Это без учета сейлзов, без которых вся эта команда сидела бы и сосала лапу.
Брукс и Гласс, например, сходятся в оценке того, что «выпустить продукт» требует примерно в 6 (шесть, Карл!) раз больших трудозатрат, чем «написать код». Поэтому логично, что и ответственность лежит на команде, а не на менеджере.
Конечно, в случае факапа, голова должна лететь в первую очередь с плеч менеджера, потому что его основные функции — планирование сроков и бюджета и управление рисками. Поэтому «правильный» менеджер видит, что кто-то из членов команды «факапит» не перед дедлайном, а своевременно. И в этом случае он не ответственность на себя будет брать и публичные заявления анонсировать, а люлей раздавать, а в случае необходимости и менять конфигурацию команды так, чтобы сроки и бюджет «сошлись».
Тут комменты посмотришь: разработчики все сплошь на галерах гребут, напрягаются во благо компании, а менеджеры смузи только пьют.
Брукс и Гласс, например, сходятся в оценке того, что «выпустить продукт» требует примерно в 6 (шесть, Карл!) раз больших трудозатрат, чем «написать код». Поэтому логично, что и ответственность лежит на команде, а не на менеджере.
Конечно, в случае факапа, голова должна лететь в первую очередь с плеч менеджера, потому что его основные функции — планирование сроков и бюджета и управление рисками. Поэтому «правильный» менеджер видит, что кто-то из членов команды «факапит» не перед дедлайном, а своевременно. И в этом случае он не ответственность на себя будет брать и публичные заявления анонсировать, а люлей раздавать, а в случае необходимости и менять конфигурацию команды так, чтобы сроки и бюджет «сошлись».
Тут комменты посмотришь: разработчики все сплошь на галерах гребут, напрягаются во благо компании, а менеджеры смузи только пьют.
Вы скажите, где менеджеры «правильные» и ведут себя так, как Вы описали. И есть ли там открытые вакансии? :)
Про совместные усилия впаривают менеджеры когда надо выйти в выходные. А по ФОТу явно видно, что программисты просто налипли на проект и ничего существенного сделать могли в принципе. Как вам 3 ведущих менеджера, 4 рядовых менеджера на команду из 7-9 разработчиков, 2.5 тестеров и 0.5 аналитика?
Я думаю, что на эту команду нужно 1 или 2 менеджера-администратора. 4 — много. При условии, что среди 7-9 разработчиков есть тимлид один.
только не 4 менеджера, а 7.
А там еще 3 ведущих))) По одному на разраба. Не знаю, это странно. Что они делают у вас?
Я уволился :-) Насмотрелся на весь этот треш и ушел. Точнее как получилось, после закрытия проекта пошел к руководству разговаривать о ЗП, мне сказали что я охренел вконец и хоть весь наш отдел строем уволится, работать всегда будет кому. Или средняя по городу, или по собственному. На улице очередь стоит. Я перешел на удаленку, ЗП в 3 раза выше геммора в 10 раз меньше.
P.S. мне эти менеджеры казались виртуальными. я их не видел. может просто чтобы освоить бюджет проекта.
P.S. мне эти менеджеры казались виртуальными. я их не видел. может просто чтобы освоить бюджет проекта.
Каждый в команде отвечает за свою часть результата. В частности разработчики за выполнение технических требований и качество кода. За сроки разработчики не отвечают, за соответствие бизнес-требований техническим — тоже.
С чего вдруг менеджер должен публично брать на себя косяки программиста, не уложившегося в срок? Если «поеахал» критический путь проекта — это ошибка менеджера. Не уложился в оценку — либо ошибка планирования, либо не соответствие занимаемой должности. Способы ослабления рисков не верной оценки известны. В статье автор явно сгущает краски: программист у него лапочка и делает все во благо компании, а менеджер — некомпетентный тиран, угнетатель. В реальности дефицит хороших кадров в IT и в разработки и в менеджменте.
> С чего вдруг менеджер должен публично брать на себя косяки программиста, не уложившегося в срок?
Потому что определение подходящего срока — это ответственность менеджера. Программист — он код фигачит и о сроках имеет весьма приблизительное представление. А менеджер как раз должен заниматься планированием производства, предугадывать косяки и усложнения по ходу дела, трезво оценивать потенциал вверенных ему программистов. Постоянно с ними общаться и убеждаться, что они не утратили видения того результата, который надо получить, и не закопались во второстепенные таски.
Программист, конечно, тоже может быть виновен в срыве сроков — если он вместо кода фигачил в танки. Но в большинстве случаев провал сроков — это провал планирования и ошибка менеджера.
Потому что определение подходящего срока — это ответственность менеджера. Программист — он код фигачит и о сроках имеет весьма приблизительное представление. А менеджер как раз должен заниматься планированием производства, предугадывать косяки и усложнения по ходу дела, трезво оценивать потенциал вверенных ему программистов. Постоянно с ними общаться и убеждаться, что они не утратили видения того результата, который надо получить, и не закопались во второстепенные таски.
Программист, конечно, тоже может быть виновен в срыве сроков — если он вместо кода фигачил в танки. Но в большинстве случаев провал сроков — это провал планирования и ошибка менеджера.
Ок, если так, то почему вы удивляетесь, что менеджер, имеющий слабое представление о технических деталях, назначает неадекватные сроки, если не хотите брать хотя-бы частично ответственно за оценку задач на себя?
Менеджер подключен к космическому знанию, предвидит будущее и так планирует сроки? Если нет, то на основании каких данных производится планирование?
Программист может оценить задачу, потому что у него есть опыт реализации аналогичных задач (если мы говорим про профессионала). Я оцениваю типовые задачи с точностью до минут. Не типовых задач в энтерпайзе на самом деле не так много, как принято считать.
Менеджер подключен к космическому знанию, предвидит будущее и так планирует сроки? Если нет, то на основании каких данных производится планирование?
Программист может оценить задачу, потому что у него есть опыт реализации аналогичных задач (если мы говорим про профессионала). Я оцениваю типовые задачи с точностью до минут. Не типовых задач в энтерпайзе на самом деле не так много, как принято считать.
Потому что если я могу вести и планировать весь проект целиком, то зачем мне менеджер?
Точное повторение старых действий (при условии неизменности окружения) — это залог идеального планирования.
А что если повторения нет, если задача отличается от той, что ты решал до этого? Нужна другая архитектура, другие библиотеки, у каждой — непредсказуемые временные затраты на внедрение. Как быть в этом случае? Программист может прикинуть лишь примерно, а затраты времени могут расти как фрактал.
Вот для этого нужен менеджер, он будет принимать решения в условиях недостатка информации. При этом он, конечно, должен извлечь в диалоге максимум информации из программиста, даже если программист стесняется говорить и пытается обойти некоторые моменты.
Потом менеджер должен решить, насколько важен проект, нужно ли закладывать больший запас ресурсов или провал сроков не критичен, и перезакладываться не нужно. Если менеджеру всё ещё слишком не понятно, сколько времени будет уходить на задачи, он может отловить программиста и вместо программирования посадить его за дизайн. Расписать вместе возможное разложение задачи на подзадачи, найти те, которые уже раньше делались и хорошо предсказываются, изолировать те, что предсказываются плохо — с ними продумать отдельно. Но это уже будет решение менеджера, ещё до начала проекта, потратить время программиста вместо программирования на анализ. Программист сам такого решения принять не может.
Точное повторение старых действий (при условии неизменности окружения) — это залог идеального планирования.
А что если повторения нет, если задача отличается от той, что ты решал до этого? Нужна другая архитектура, другие библиотеки, у каждой — непредсказуемые временные затраты на внедрение. Как быть в этом случае? Программист может прикинуть лишь примерно, а затраты времени могут расти как фрактал.
Вот для этого нужен менеджер, он будет принимать решения в условиях недостатка информации. При этом он, конечно, должен извлечь в диалоге максимум информации из программиста, даже если программист стесняется говорить и пытается обойти некоторые моменты.
Потом менеджер должен решить, насколько важен проект, нужно ли закладывать больший запас ресурсов или провал сроков не критичен, и перезакладываться не нужно. Если менеджеру всё ещё слишком не понятно, сколько времени будет уходить на задачи, он может отловить программиста и вместо программирования посадить его за дизайн. Расписать вместе возможное разложение задачи на подзадачи, найти те, которые уже раньше делались и хорошо предсказываются, изолировать те, что предсказываются плохо — с ними продумать отдельно. Но это уже будет решение менеджера, ещё до начала проекта, потратить время программиста вместо программирования на анализ. Программист сам такого решения принять не может.
Для этого нужен не менеджер, а архитектор. Менеджер не знает всего этого: он наймет правильного человека, получит оценки и проанализирует риски. Ничего более точного еще не придумали.
Мы говорили, не про оценку всего проекта, а про то что нужно укладываться в оценки по своим задачам. Планировать весь проект разработчика ни один грамотный руководитель не попросит.
Мы говорили, не про оценку всего проекта, а про то что нужно укладываться в оценки по своим задачам. Планировать весь проект разработчика ни один грамотный руководитель не попросит.
Э… Извините, что? Менеджер не знает, что такое иерархическое дерево работ? Да, для его построения ему нужен специалист в разработке, к которому он придет с верхнеуровневым деревом (эпики, фичи, стори), а тот уже разобьет на тривиальные оценки.
Правда, эта вся фигня с диаграммами Ганта выглядит красиво в ПМБуке, в Прожекте каком-нибудь, а вот в реальном проекте вдруг выясняется, что заказчик хотел не этого, а вот того. Это должно быть не так, а вот этак. Ну и все первоначальные оценки или идут в корзину, или идет торг на уровне «мы сделаем это, но выкинем вот это», или идет раздувание сроков-бюджетов. Там куча всяких интересных вариантов. Опять же будет своя специфика с внутренней разработкой, продуктовой, заказной. Не зря же пытаются всякие итеративные, инкрементальные способы разработки внедрять. Как раз из этих соображений, что самая адекватная оценка, это оценка полученная в процессе работы. Да и чем дольше идет проект, тем лучше предсказание рисков и все такое.
Правда, эта вся фигня с диаграммами Ганта выглядит красиво в ПМБуке, в Прожекте каком-нибудь, а вот в реальном проекте вдруг выясняется, что заказчик хотел не этого, а вот того. Это должно быть не так, а вот этак. Ну и все первоначальные оценки или идут в корзину, или идет торг на уровне «мы сделаем это, но выкинем вот это», или идет раздувание сроков-бюджетов. Там куча всяких интересных вариантов. Опять же будет своя специфика с внутренней разработкой, продуктовой, заказной. Не зря же пытаются всякие итеративные, инкрементальные способы разработки внедрять. Как раз из этих соображений, что самая адекватная оценка, это оценка полученная в процессе работы. Да и чем дольше идет проект, тем лучше предсказание рисков и все такое.
А что если повторения нет, если задача отличается от той, что ты решал до этого? Нужна другая архитектура, другие библиотеки, у каждой — непредсказуемые временные затраты на внедрение. Как быть в этом случае? Программист может прикинуть лишь примерно, а затраты времени могут расти как фрактал.
Я имел в виду, что разработчик отвечает за свои оценки. Остальное, видимо, все поняли по-своему
Я разработчик, я отвечаю за свои оценки. Приходит ко мне менеджер и говорит: «Сколько?»
Ну я же отвечаю, за свои оценки, поэтому я, прикинув, что задача на 2 часа, но придет менеджер Петя и попросит подсказать как сделано А, потом забежит аналитик Света и попросит посмотреть нормальное ли требование Б, потом может быть недоступен тестовый стенд, дам оценку в 10 часов.
Что скажет на это менеджер?
Ну я же отвечаю, за свои оценки, поэтому я, прикинув, что задача на 2 часа, но придет менеджер Петя и попросит подсказать как сделано А, потом забежит аналитик Света и попросит посмотреть нормальное ли требование Б, потом может быть недоступен тестовый стенд, дам оценку в 10 часов.
Что скажет на это менеджер?
Это все хрень. Организуйте свою работу так, чтобы тестовый стенд работал и Васи и Светы не забегали и делайте за 3 часа.
Э… Я как разработчик должен организовать свою работу так, чтобы меня не дергали менеджеры, аналитики, тестировщики, заказчики. Точно? За это отвечает не менеджер? Т.е. я должен послать вас когда вы придете ко мне за оценкой? Так? Если да, то зачем вы пришли?
Я как разработчик должен договориться с отделом эксплуатации чтобы мне развернули нужный тестовый стенд или это ваша работа как менеджера?
Чтобы не было недоразумений, я уже лет 7 как менеджер, а первые подчиненные у меня появились лет 15 назад.
Мы живем в мире с высокой неопределенностью. Разработчик дал вам оценку в 16 часов. А потом у него подскочила температура и он ушел в больницу. Вы его не отпустите? Или это он виноват, что не решил задачу за 16 часов?
Я как разработчик должен договориться с отделом эксплуатации чтобы мне развернули нужный тестовый стенд или это ваша работа как менеджера?
Чтобы не было недоразумений, я уже лет 7 как менеджер, а первые подчиненные у меня появились лет 15 назад.
Мы живем в мире с высокой неопределенностью. Разработчик дал вам оценку в 16 часов. А потом у него подскочила температура и он ушел в больницу. Вы его не отпустите? Или это он виноват, что не решил задачу за 16 часов?
Я говорю только про риск «низкая производительность труда». Падения метеоритов, температура и прочее случаются. Все это понимают.
И я про 3 часа которые в ворк-логах, а не календарные.
И я про 3 часа которые в ворк-логах, а не календарные.
Если разработчику мешают и поэтому он не укладываются, нужно сказать, так и так я по факту не работаю, а болтаю с аналитиками и отделом внедрения. Светку надо уволить, потому что дура она, а не аналитик. С заказчиками должны общаться акаунты. Тестировщики могут спокойно писать баг-репорты в Jira. Заниматься разработчик должен тем о чем сказал на стендапе. Вы описали не неопределенность, а бардак.
Я просто напомню с чего все началось.
> С чего вдруг менеджер должен публично брать на себя косяки программиста, не уложившегося в срок?
Если менеджер не может организовать работу программиста чтобы он укладывался в срок. Обратите внимание, не программист должен это обеспечить, а менеджер. Если менеджер не может вовремя уволить человека который не укладывается в сроки (когда то что мешает программисту устраняется, а программист все равно халявит) и заменить его другим. Если менеджер не заложил буферы на то, что время от времени задачи даже выполняемые повторно будут занимать больше времени по объективным причинам.
То? При чем здесь программист?
Вы не подумайте, у меня в подчинении очень хорошие программисты, которые эффективно делают свою работу. Но если один из проектов, за которые я несу ответственность не будет соответствовать заявленным требованиям (функциональным, нефункциональным, по срокам реализации, по бюджету), то ответственность перед заказчиками несу в первую очередь я. передо мной несут ответственность руководители проектов. А если мне руководитель проекта придет и скажет, что проект сфейлился, потому что Вася уже три месяца не делает вовремя порученные ему задачи. То надо уволить этого менеджера, т.к. он не решил проблему за 3 месяца, ну и следом меня, т.к. о том что на проекте 3 месяца идет отставание по срокам я узнал в день релиза.
> С чего вдруг менеджер должен публично брать на себя косяки программиста, не уложившегося в срок?
Если менеджер не может организовать работу программиста чтобы он укладывался в срок. Обратите внимание, не программист должен это обеспечить, а менеджер. Если менеджер не может вовремя уволить человека который не укладывается в сроки (когда то что мешает программисту устраняется, а программист все равно халявит) и заменить его другим. Если менеджер не заложил буферы на то, что время от времени задачи даже выполняемые повторно будут занимать больше времени по объективным причинам.
То? При чем здесь программист?
Вы не подумайте, у меня в подчинении очень хорошие программисты, которые эффективно делают свою работу. Но если один из проектов, за которые я несу ответственность не будет соответствовать заявленным требованиям (функциональным, нефункциональным, по срокам реализации, по бюджету), то ответственность перед заказчиками несу в первую очередь я. передо мной несут ответственность руководители проектов. А если мне руководитель проекта придет и скажет, что проект сфейлился, потому что Вася уже три месяца не делает вовремя порученные ему задачи. То надо уволить этого менеджера, т.к. он не решил проблему за 3 месяца, ну и следом меня, т.к. о том что на проекте 3 месяца идет отставание по срокам я узнал в день релиза.
Интересно, как разработчику запретить дергать себя другим людям? Вот посадило начальство 10-15 человек половина которых программисты, а вторая аналитики и менеджеры в один кабинет, и крутись как хочешь. В результате задачи на 30-40 минут растягиваются на все 8ч, из которых 6 часов тебя дергают разные люди с вопросами или левыми задачами (уточнить тп, рассказать как пользоваться фичей, нарисовать схему для заказчика, обсудить какие нибудь требования с заказчиком, подбежать с багом «ну тут же на 5 минут исправить, глянь по быстрому» и т.п.) и все это сопровождается постоянными телефонными звонками, гоготом, разговорами в стиле «а вокруг России одни враги, а Люба разошлась со своим то, а вот начальник из Москвы фотки из европы показывал», остальное время тратишь на вспоминание «а что же я там уже успел по задаче сделать» и на попытку внести задачи в систему тайм-трекинга. И потом еще виноват оказываешься что медленно работаешь, да еще и система тайм трекинга показывает дикие трудозатраты на получасовую задачу (не будешь же 5минутный разговор заносить, а требуется внести ровно 40 часов в неделю)
Я часто менеджеру и топ-боссам говорю: «разрешите мне работать из дома, не читать почту, игнорировать все сообщения/звонки от коллег кроме ваших лично и я сделаю эту задачу за неделю, если сами же другие задачи поручать не будете. А так, оптимистичная оценка — месяц, средняя — два». Раза три прокатывало, один из них, правда, сказали работать в офисе партнеров.
Ставьте себе график — 40 минут работаете, 20 — перерыв. Из них 10 — перекур/прогулка/чай/беседы на отвлеченные тем, 10 — преговоры с коллегами. Все не срочные вопросы перенести в текстовое общение и отвечать в асинхронном режиме. Довести до коллег свой распорядок. Во многих организациях такой распорядок закреплен руководством.
В том-то и дело, что не отвечает в общем случае. Не должен отвечать. Он даёт прогноз, а не результаты спиритического сеанса. Вы же не считаете, что синоптики должны отвечать за результаты своих прогнозов? Или политические аналитики?
Тогда руководитель не отвечает за своевременность выплаты заработной платы, а менеджер за сроки проектов. Они дают прогнозы и гадают на картах Таро.
Простите, что вмешиваюсь в ваш спор.
Мне кажется, что разработчики часто не отвечают за свои прогнозы.
Но иногда отвечают и таких разработчиков ставят сеньорами и тимлидами.
Мне кажется, что разработчики часто не отвечают за свои прогнозы.
Но иногда отвечают и таких разработчиков ставят сеньорами и тимлидами.
Тимлидами ставят тех, кто готов отвечать за всю команду, как ни странно. И тимлид — уже скорее менеджер, чем разработчик. Почему я и отбрыкиваюсь от попыток делать меня тимлидом. Сеньором, архитектором, техлидом — пожалуйста. Но отвечать за свои, а, тем более чужие, прогнозы и, тем более, косяки — увольте. Не увольняют почему-то.
Прошу прощения. Программисты не должны отвечать за сроки.
Они должны отвечать за код!
Точнее за качество кода.
Чтобы при добавлении новой фичи
1) Количество ошибок на фичу не увеличивалось
2) Время на добавление фичи не росло в экспоненциально.
Потому что «выигранное» X времени сейчас, выльются в e^X потом.
Они должны отвечать за код!
Точнее за качество кода.
Чтобы при добавлении новой фичи
1) Количество ошибок на фичу не увеличивалось
2) Время на добавление фичи не росло в экспоненциально.
Потому что «выигранное» X времени сейчас, выльются в e^X потом.
Поверьте на слово — идеальный код, законченный к моменту провала проекта — гораздо хуже, чем плохонький, но работающий и решающий чьи-то проблемы.
Кроме того — если программисты не отвечают за сроки, то откуда вообще их брать?
В предыдущих комментариях, да и в тексте поста есть определенное недовольство тем, что менеджеры высасывают сроки из пальца. По вашему получается, что это нормальная ситуация.
Кроме того — если программисты не отвечают за сроки, то откуда вообще их брать?
В предыдущих комментариях, да и в тексте поста есть определенное недовольство тем, что менеджеры высасывают сроки из пальца. По вашему получается, что это нормальная ситуация.
В большинстве случаев объективной привязки (кроме бюджета на разработку и подобных финансовых кейсов) к каким-то датам нет, просто нужно как можно скорее. И менеджменту сроки окончания разработки нужны для привязки других мероприятий типа резервирования рекламных мест, набора расширенного штата, аренда новых помещений и т. п. Или наоборот, подготовки к сокращению штата и т. д. Менеджмент любит параллельные процессы, чтобы к моменту готовности продукта его сразу запускать в эксплуатацию, не неся дополнительных расходов за слишком раннее проведение других мероприятий и не теряя потенциального дохода за время простоя продукта из-за их неосуществления.
Ага. А потом менеджмент, который принимает слова программиста за чистую монету проводит массивную рекламную компанию в 1983м в то время как продукт выходит в 1985м. Собственно задача менеджера любой компании, которая что-то разрабатывает — научиться как-то с этим жить. И разработка нового сайта тут ничем не отличается от задачи разработки нового Boing'а: и там и там устраивать разработчикам разносы — лучший способ остаться с «разбитым копытом».
Потому что определение подходящего срока — это ответственность менеджера. Программист — он код фигачит и о сроках имеет весьма приблизительное представление.
Надеюсь вы не имеете в виду, что сроки выполнения задач должны определять менеджеры вместо программистов?
Потому что программист срок в который он уложится обычно не называет. Он даёт вероятностную оценку трудозатрат (или вообще абстрактные поинты, привязанные к сложности), по которой менеджер, пользуясь своими профессиональными знаниями, навыками и опыту, сообщает сроки руководству. Очень часто в форме обязательства. Если сроки сорваны, то это ответственность прежде всего менеджера — неправильно оценил риски. И, скорее всего, не заметил имеющиеся признаки срыва заранее. Или заметил, но толком ничего не предпринял.
Думаю, вина не может быть абсолютной, все зависит от того, кто кому обещал и кто обещание не выполнил.
Разработчик обещает менеджеру, менеджер обещает начальству.
Разработчик виноват перед менеджером, менеджер перед начальством.
Если разработчик начальству ничего не обещает, то он перед ней и не виноват.
Думаю мыслю поняли.
Разработчик обещает менеджеру, менеджер обещает начальству.
Разработчик виноват перед менеджером, менеджер перед начальством.
Если разработчик начальству ничего не обещает, то он перед ней и не виноват.
Думаю мыслю поняли.
У менеджеров и начальства есть склонность принимать оценки, планы, прогнозы за обещания.
Это нормально. Они сделали ставку на то, что разрабы, могут притворить эти планы и прогнозы в жизнь. В худшем случае ставка не сыграет.
Разработчик виноват в неверной оценке.
Руководство — в том, что доверилось прогнозу(оценке).
Оправдания никому не нужны. Ситуация в которой менеджер «оправдывает» себя, тем что ему обещали подчиненные — яйца выйденного не стоит. Он просто не хочет признать свою вину.
Начальство должно наказать менеджера, менеджер — подчиненного.
Будет печально если все шишки посыпятся только на разработчика.
Разработчик виноват в неверной оценке.
Руководство — в том, что доверилось прогнозу(оценке).
Оправдания никому не нужны. Ситуация в которой менеджер «оправдывает» себя, тем что ему обещали подчиненные — яйца выйденного не стоит. Он просто не хочет признать свою вину.
Начальство должно наказать менеджера, менеджер — подчиненного.
Будет печально если все шишки посыпятся только на разработчика.
Интересно, в чем виноват разработчик если он оценил фичу в неделю, менеджер сказал ок, навесил еще 2 задачи по два дня, и в итоге спрашивает в конце недели почему ничего не готово?
Он должен был отказатся от этих 2 задач.
Ну, или отложить релиз фичи. В таком случае об этом надо доносить, тому кому эта фича была «обещана».
Ну, или отложить релиз фичи. В таком случае об этом надо доносить, тому кому эта фича была «обещана».
А в том и проблема что бесполезно это объяснять. Особенно когда над головой несколько менеджеров, каждый свою задачу приоритетной считает, и каждый, несмотря на то что прямо заявляешь что это названное время работы — не срок, а именно время работы над задачей, будет ожидать результата через время названное разработчиком. Ну и отказаться возможности нет (даже временно), принцип: я начальник — ты дурак.
Хороший менеджер — это тимлид. И как раз ответственность тимлида оценивать сроки.
В случае же когда разговаривают менеджер и разработчик проблема не в менеджере и не в разработчике а в человеке, который поставил их разговаривать друг с другом.
Тимлид — человек вышедший из разработки, как правило половину времени уделяет распределению задач, написанию ТЗ, донесением до менеджеров и руководства всей сути технической работы)
В случае же когда разговаривают менеджер и разработчик проблема не в менеджере и не в разработчике а в человеке, который поставил их разговаривать друг с другом.
Тимлид — человек вышедший из разработки, как правило половину времени уделяет распределению задач, написанию ТЗ, донесением до менеджеров и руководства всей сути технической работы)
Когда-то я был малым и глупым и работал в компании где директор разговаривал напрямую с разработчиком(мной, при этом еще студентом). Тогда разработчик сдуру согласился писать новый проект за пару недель, как очень хотело руководство. Удивительно, но проект не был закончен вовремя и разработчику предложили поработать еще в режиме 18 часов кодинга в день 7 дней в неделю. После этого последовало очень неожиданно для директора последовало ПСЖ.
Так что да, в компаниях где нет тимлида самое разумное действие разработчика — писать ПСЖ. А еще лучше даже не пытаться устраиваться в такую компанию.
P.S. После этого наняли тимлида и переписали и старый и новый проекты с Явы на C++. Потому что новый тимлид не знал Яву) И это все равно было лучше, чем без тимлида.
Так что да, в компаниях где нет тимлида самое разумное действие разработчика — писать ПСЖ. А еще лучше даже не пытаться устраиваться в такую компанию.
P.S. После этого наняли тимлида и переписали и старый и новый проекты с Явы на C++. Потому что новый тимлид не знал Яву) И это все равно было лучше, чем без тимлида.
хороший считает (и не в глубине души, а публично заявляет), что это его ошибка, что он оценку разработчиков выдал за свое обязательство.
Правило Вестгеймера Чтобы определить, сколько времени потребует работа, возьмите время которое, по-вашему на нее необходимо, множьте на 2 и замените единицы измерения на единицы более высокого порядка. Так, мы выделяем два дня на одночасовую работу.
UFO just landed and posted this here
Обычно программисты имеют низкий социальные навыки
Сморозили чушь, наделали ошибок, да еще и полхабра оскорбили. Nice work!
Вы либо толстый зеленый тролль, либо феерический долбоеб.
Простите меня за мой французский, но я безмерно возмущен!
Простите меня за мой французский, но я безмерно возмущен!
Это значит то, что менеджер:
— не прислушивается к своим разработчикам (грубо говоря, не доверяет).
— боится, что правильный подход будет слишком сложным для начинающего чайника, который заменит разработчика (если тот уйдёт).
— пытается применить к новому проекту свой совершенно нерелевантный опыт из старого проекта, который был сделан из совершенно другого конструктора.
и ещё тысяча других причин.
— не прислушивается к своим разработчикам (грубо говоря, не доверяет).
— боится, что правильный подход будет слишком сложным для начинающего чайника, который заменит разработчика (если тот уйдёт).
— пытается применить к новому проекту свой совершенно нерелевантный опыт из старого проекта, который был сделан из совершенно другого конструктора.
и ещё тысяча других причин.
Надо что-то делать с текстом, а то слово «говно» в нем уже стало техническим долгом. То «гавно», то «говно» — вы уж на гОвно замените везде.
Или это как пример технического же долга?
Или это как пример технического же долга?
Как пример технического долга я вставил off by one error в нумерации частей. Спасибо что заметили.
Спасибо за момент, когда пол-ежа заливают сверху говном. Это — самое жизненное.
Реальный случай с совещания, когда топ-менеджмент предлагал разрабу, чтобы старый 16-битный код запустить в 32-битном окружении, просто забить нулями вторую половину каждого 32-битного слова. И это, замечу, было техническое руководство, которое увидело способ быстро интегрировать старый, совсем доисторический, код с более новым, просто доисторическим.
Разраб, когда после совещания отошел немного, пошел и написал «по собственному».
Реальный случай с совещания, когда топ-менеджмент предлагал разрабу, чтобы старый 16-битный код запустить в 32-битном окружении, просто забить нулями вторую половину каждого 32-битного слова. И это, замечу, было техническое руководство, которое увидело способ быстро интегрировать старый, совсем доисторический, код с более новым, просто доисторическим.
Разраб, когда после совещания отошел немного, пошел и написал «по собственному».
Неплохо и довольно жизненно)
> система КРОТОПОН, которая работает на продакшане заглючила и мы потеряли кучу денег.
Так и не смог разгадать ребус и вычислить название реальной системы(
Поделитесь? )
Так и не смог разгадать ребус и вычислить название реальной системы(
Поделитесь? )
Напомнило «Проект Генезис»
До слёз
спасибо, у меня сейчас такой сценарий разыгрывается :) уже второй менеджер :))
Всё верно, кроме последнего абзаца. Компания не разоряется, продукт-то работает. Ну и пофиг что костыли, ынтырпрайз же. Продукт продают, для поддержки достаточно макак. Опять же на премии и повышении сэкономили.
Так оно и задумывается на борде, ваще та. А готового выгореть разраба можно и нового найти.
Так оно и задумывается на борде, ваще та. А готового выгореть разраба можно и нового найти.
Довольно поучительно и наглядно для демонстрации того, к чему приводит длительное забивание на технический долг. Однако, довольно сильно идеализировано, и менеджер все-таки чересчур демонизирован( хотя, в этой конкретно ситуации он реально самодур). Все это похоже на разработку какого-то внутреннего продукта больше для нужд самой компании. А давайте представим, что где-то в антракте между третьей и четвертой частью ( наиболее подходящее место, как мне кажется ), на сцену врывается Конкурент (К), и начинает неистово рекламировать свой ( как потом окажется, не совсем еще стабильный, но пофигу — главное, сейчас нишу захватить и пользователя подсадить. И пофигу, что костыли — они же у нас армированные(!), потом заменим ) продукт, да еще со скидкой, да еще с бесплатным тестовым периодом. В результате, начиная с 4-й части, менеджер будет где-то вынужден идти на «непопулярные» меры, в противном случае проект ( а может, и компания ) рискуют не дожить до концовки пьесы, ибо продукт-то хорош, а толку-то с него, аудитория уже захвачена и накрепко подсажена на продукт К, а ресурсов ждать, пока пользователь осознает, какие вы крутые, и продвигать эту свою крутость в массы, попросту нет. Ввиду пока еще высокой динамики развития отрасли ИТ такой сценарий видится гораздо более реальным, да и практика показывает то же самое.
Идеальный управленец вообще не должен иметь конфликт интересов со своими разработчиками. Наоборот, он должен быть арбитром между конечным заказчиком/пользователем и своей командой. Но это в идеале. А так то, что довольно часто проект становится жертвой субъективизма менеджмента, тут вы правы, ничего не поделаешь…
Идеальный управленец вообще не должен иметь конфликт интересов со своими разработчиками. Наоборот, он должен быть арбитром между конечным заказчиком/пользователем и своей командой. Но это в идеале. А так то, что довольно часто проект становится жертвой субъективизма менеджмента, тут вы правы, ничего не поделаешь…
Неспроста ж случается, что з/п у П бывает повыше чем у его М.
Хорошо еще что только до М3 добрались, а не дальше. Сполз под стол, спасибо!
Очень жалко программиста :(
Вообще говоря, пьесы не так пишутся. В пьесе у персонажей есть имена и фамилии, а их роли и характеры раскрываются в результате взаимодействия и диалогов в различных ситуациях. Читатель не должен сразу знать, кто есть кто, а должен сам распознать это по ходу пьесы. В этом вся соль. Без этого пьеса — не пьеса...
UFO just landed and posted this here
У меня немного другая история была, как-то 1.5 года оттимлидил на проекте где 3 ПМа сменилось, причем не с повышением, а с увольнением ПСЖ. Ситуацию они особо не контролировали, но служили неплохим буфером между заказчиком и командой разработки. Когда случались факапы (а случались они постоянно :)), они самоотверженно получали люлей, потому наверное и не выдерживали подолгу… Ну а в целом проект закончился успешно, стал хорошим пунктом в моем CV, и я благодарен этим ребятам за то что спасали мою нервную систему.
Это хороший пример что будет, если понимать все буквально, биться головой в стену и считать работой программиста написание кода, сверяясь с книжкой «Идеальный код» МакКонела.
В компании есть деньги, менеджер, СЕО и випы заинтересованы чтобы проект был принят. Этого достаточно чтобы где-то сделать по-своему, где-то сорвать сроки, где-то скорректировать требования, кого-то мягко проигнорировать, но сделать что-то работающее, что будет принято и будет развиваться дальше и может и будет кривое, но работающее и даже приносящее прибыль компании. Получить соответственно повышение зп и бонус.
Просто надо быть хитрее.
В компании есть деньги, менеджер, СЕО и випы заинтересованы чтобы проект был принят. Этого достаточно чтобы где-то сделать по-своему, где-то сорвать сроки, где-то скорректировать требования, кого-то мягко проигнорировать, но сделать что-то работающее, что будет принято и будет развиваться дальше и может и будет кривое, но работающее и даже приносящее прибыль компании. Получить соответственно повышение зп и бонус.
Просто надо быть хитрее.
А потом «это» десяток лет развивать и поддерживать, плюс под каждый проект чуть ли не с нуля переписывать, потому что модифицировать «это» в адекватные сроки и без миллиона ошибок нереально.
Тут надо понимать, что вы хотите
а) писать очень «правильный» софт с грамотными: ТЗ, архитектурой, выбранными технологиями, процессами разработки и деплоя, покрытиями тестами и современными стандартами по написанию самого кода.
б) долго работать программистом в крупной компании с повышениями и ростом ЗП.
Действия в статье описаны для человека, который хочет исключительно пункт А.
Можно для себя выбрать Б, а из «а» брать по возможности.
«А потом «это» десяток лет развивать и поддерживать» — ответил ниже.
а) писать очень «правильный» софт с грамотными: ТЗ, архитектурой, выбранными технологиями, процессами разработки и деплоя, покрытиями тестами и современными стандартами по написанию самого кода.
б) долго работать программистом в крупной компании с повышениями и ростом ЗП.
Действия в статье описаны для человека, который хочет исключительно пункт А.
Можно для себя выбрать Б, а из «а» брать по возможности.
«А потом «это» десяток лет развивать и поддерживать» — ответил ниже.
Угу.
Не реализовать в системе часть функциональности, поставив имитатор.
А когда к клиенту нагрянет регулятор и натянет его по всей строгости (а то и посадит кого из его работников) — сделать честный вид и сказать «но ведь вы нам акты подписали», да.
Или для скорости наворотить неописанных костылей, а когда костылестроитель покинет компанию — задуматься, а как все это безобразие поддерживать. И кем.
Не реализовать в системе часть функциональности, поставив имитатор.
А когда к клиенту нагрянет регулятор и натянет его по всей строгости (а то и посадит кого из его работников) — сделать честный вид и сказать «но ведь вы нам акты подписали», да.
Или для скорости наворотить неописанных костылей, а когда костылестроитель покинет компанию — задуматься, а как все это безобразие поддерживать. И кем.
Из-за вашего кода посадят кого-то в компании заказчика? Ерунда какая-то.
Neikist: «А потом «это» десяток лет развивать и поддерживать, плюс под каждый проект чуть ли не с нуля переписывать» зачастую это может быть и неплохо.
Надо смотреть что это за система, если это управление аппаратом по лазерной коррекции зрения- там я бы так делать не стал.
А если скажем… какой-нить документооборот в крупной компании- именно так как вы описали оно и делается в 90% не-айтишных компаний, например в строительной или нефтедобывающей. Эти все велосипеды на костылях потом надо поддерживать и дописывать- штат сотрудников увеличивается, а это означает повышение, рост зарплат.
Neikist: «А потом «это» десяток лет развивать и поддерживать, плюс под каждый проект чуть ли не с нуля переписывать» зачастую это может быть и неплохо.
Надо смотреть что это за система, если это управление аппаратом по лазерной коррекции зрения- там я бы так делать не стал.
А если скажем… какой-нить документооборот в крупной компании- именно так как вы описали оно и делается в 90% не-айтишных компаний, например в строительной или нефтедобывающей. Эти все велосипеды на костылях потом надо поддерживать и дописывать- штат сотрудников увеличивается, а это означает повышение, рост зарплат.
Ну скажем так — при фактической нереализации одной фичи посадить могут некоего невиновного человека (если, конечно, неработоспособность фичи не будет вскрыта).
Например, произойдет утечка данных с меткой этого человека, хотя по факту он будет непричастен.
Повышение и рост зарплат это означает в тучные годы.
А когда основной клиент-кормилец начинает вместо договоров предлагать держаться и желать всего доброго, хорошего настроения и здоровья — вот тут и начинаются основные проблемы с поддержкой как остальных пользователей этого продукта, так и пожелавшего сэкономить на поддержке основного.
И наиболее толковые сотрудники начинают искать счастья на стороне. Что еще больше усугубляет непонимание, как оно работает.
Например, произойдет утечка данных с меткой этого человека, хотя по факту он будет непричастен.
Повышение и рост зарплат это означает в тучные годы.
А когда основной клиент-кормилец начинает вместо договоров предлагать держаться и желать всего доброго, хорошего настроения и здоровья — вот тут и начинаются основные проблемы с поддержкой как остальных пользователей этого продукта, так и пожелавшего сэкономить на поддержке основного.
И наиболее толковые сотрудники начинают искать счастья на стороне. Что еще больше усугубляет непонимание, как оно работает.
Это какой-то экстремальный случай- с посадкой. 95% софта все-так не несет серьезных последствий в случае уязвимостей/багов/недоработок. И отделен от программиста несколькими слоями- тестирование, приемка, проверка на уязвимости, поддержка на лайве.
Попробую еще другими словами дополнить свою мысль.
Разработчик — это не тот, кто отвечает за проект. Описанный в статье разработчик переживает насчет вещей, которые вообще не находятся в его компетенции. Он не знает, на каких исходных данных принимались решения выше, может это политические игры руководства и через 2 года этот продукт вообще не будет нужен. А может нужен, но они ошиблись в решениях. Но ошиблись то — они, а не разработчик.
Это как сборщик айфонов в Китае будет переживать — а как же таким телефоном будут пользоваться люди, неудобно ведь и неоправданно дорого! А через год все их повыкидывают и будут покупать новые! А старые станут такими медленными на новой оси. И уволится из-за этого, хотя предлагали нормальную зп.
Попробую еще другими словами дополнить свою мысль.
Разработчик — это не тот, кто отвечает за проект. Описанный в статье разработчик переживает насчет вещей, которые вообще не находятся в его компетенции. Он не знает, на каких исходных данных принимались решения выше, может это политические игры руководства и через 2 года этот продукт вообще не будет нужен. А может нужен, но они ошиблись в решениях. Но ошиблись то — они, а не разработчик.
Это как сборщик айфонов в Китае будет переживать — а как же таким телефоном будут пользоваться люди, неудобно ведь и неоправданно дорого! А через год все их повыкидывают и будут покупать новые! А старые станут такими медленными на новой оси. И уволится из-за этого, хотя предлагали нормальную зп.
А.
Я понял ваш первый комментарий как «менеджер сказал запилить фичу в нереальные сроки, сделаю ему имитацию чтобы приемочные прошло, а там — не моя проблема».
Я понял ваш первый комментарий как «менеджер сказал запилить фичу в нереальные сроки, сделаю ему имитацию чтобы приемочные прошло, а там — не моя проблема».
А, тогда понятен ваш комментарий :)
Да, я имел ввиду «менеджер сказал запилить фичу в нереальные сроки, сделаю что-то работающее, но не все. А как он объяснит начальству что успели сделать не все — не моя проблема».
Еще дополню свою мысль :)
М: смог вытащить этот проект за такой малый срок. Так что меня повысили
М2: Какие мы молодцы… я вместе с Гуру перевожусь в другой отдел
«и решают сделать новую систему» — под руководством М3, видимо.
Т.е. М, М2, М3 и Гуру- в шоколаде (4 чел).
А разработчик: в какашках (1 чел)
И это все по результатам работы над одним и тем же проектом! Ну и кто из этих 5ти людей некомпетентный дуралей? :)
«Так и сказали, что я мастер управлением персоналом, что смог вытащить этот проект за такой малый срок. Так что меня повысили». Вот на этом моменте разрабу надо было ультимативно получать повышение, либо уходить с повышением зп. А когда дошло бы до «решают сделать новую систему» — получить еще 2 разраба и еще одно повышение.
Да, я имел ввиду «менеджер сказал запилить фичу в нереальные сроки, сделаю что-то работающее, но не все. А как он объяснит начальству что успели сделать не все — не моя проблема».
Еще дополню свою мысль :)
М: смог вытащить этот проект за такой малый срок. Так что меня повысили
М2: Какие мы молодцы… я вместе с Гуру перевожусь в другой отдел
«и решают сделать новую систему» — под руководством М3, видимо.
Т.е. М, М2, М3 и Гуру- в шоколаде (4 чел).
А разработчик: в какашках (1 чел)
И это все по результатам работы над одним и тем же проектом! Ну и кто из этих 5ти людей некомпетентный дуралей? :)
«Так и сказали, что я мастер управлением персоналом, что смог вытащить этот проект за такой малый срок. Так что меня повысили». Вот на этом моменте разрабу надо было ультимативно получать повышение, либо уходить с повышением зп. А когда дошло бы до «решают сделать новую систему» — получить еще 2 разраба и еще одно повышение.
А меня вот интересует, откуда берутся подобные Гуру?
Вот у знакомых команда без менеджера, с самыми высокими показателями в компании.
Был на всех трёх местах ;D отлично, отлично..
Хм… я видел обратную картину:
М: мне бы тут отчет сделать небольшой, пару SQL-запросов в Excel выкинуть…
Р: ну это на неделю работы… и премию надо… и ТЗ точное… а еще надо библиотеку изучить для формирования Excel-файла…
М: Мне завтра надо. И вообще это — однократная работа. Выгрузи уж как нибудь вот эти и вот эти столбцы.
Р: ну мне некогда ерундой заниматься и пишет служебку на 3 страницы, почему это сделать нельзя
М с боем выбивает доступ на чтение к СУБД у админов, остается вечерком, ваяет запросы и копипастит их в Excel…
Задача выполнена.
По мотивам реальных событий, рассказанных одним экономистом (собственно он и был М) в одной большой компании.
М: мне бы тут отчет сделать небольшой, пару SQL-запросов в Excel выкинуть…
Р: ну это на неделю работы… и премию надо… и ТЗ точное… а еще надо библиотеку изучить для формирования Excel-файла…
М: Мне завтра надо. И вообще это — однократная работа. Выгрузи уж как нибудь вот эти и вот эти столбцы.
Р: ну мне некогда ерундой заниматься и пишет служебку на 3 страницы, почему это сделать нельзя
М с боем выбивает доступ на чтение к СУБД у админов, остается вечерком, ваяет запросы и копипастит их в Excel…
Задача выполнена.
По мотивам реальных событий, рассказанных одним экономистом (собственно он и был М) в одной большой компании.
Совсем не обратная. Экономист пытался заставить разработчика заниматься не разработкой, а работой с данными. разработчик же, как ни странно, должен разрабатывать, а не данные кому-то выгружать.Слышим «выгрузи как-нибудь в Excel», понимаем: «разработать модуль выгрузки в Excel»/ Как поставлена задача, так и оценки времени разработки и даются. Мог бы поставить задачу: «напиши мне SQL-запросы, которые делают вот такую выборку» и оценка была бы другой.
Хм… и куда экономист должен воткнуть эти SQL-запросы?
Собственно, если бы экономист не вытягивал, то компания теряла бы неслабые деньги.
Странно что у программиста в этом случае нашлось время на написание служебки на 3 страницы )
p.s. что в истории совпадает, так это то, что премию дали экономисту )
Собственно, если бы экономист не вытягивал, то компания теряла бы неслабые деньги.
Странно что у программиста в этом случае нашлось время на написание служебки на 3 страницы )
p.s. что в истории совпадает, так это то, что премию дали экономисту )
А не суть куда воткнут эти запросы. Разработчику поставлена задача, которая не является задачей для разработчика. А именно взять данные из таблички и скопипастить в ексель. Вполне нормально, что разработчик всеми силами от нее избавляется, поскольку иначе будет поставлена вторая такая же задача завтра, и разработчик превратится в секретаря(accounter на английском).
Разработчику поставлена задача, которая не является задачей для разработчика.
Ну вот у бизнеса возникла задача — отдать клиенту в экселе какие-то данные. Сделать надо завтра. Кому, кроме разработчика, можно поручить такую задачу?
Вина «бизнеса», раз не определили заранее, кто должен этим заниматься.
По хорошему разработчика не должны к данным вообще подпускать.
По хорошему разработчика не должны к данным вообще подпускать.
У бизнеса все определено. Схему данных понимает только разработчик, поэтому запрос будет писать он. Выполнять запрос будет не он, а тот, кто имеет право на доступ к данным.
А вот и нет. Перечитайте постановку задачи и решение. Очевидно, что схему как минимум понимает менеджер и способен сам получить нужные данные и уж отчет то — точно его часть.
Постановка задачи — сделать пару sql запросов для отчёта.
Тот факт, что менеджер понимает схему свидетельствует о том, что разработчику попался технически грамотный менеджер, а не о том, что менеджер обязан понимать схему данных. Для этого есть разработчики.
Тот факт, что менеджер смог получить данные — чудо. В нормальной ситуации отказ разработчика делать запрос означает, что клиент не получит того, что ему было нужно.
Тот факт, что менеджер смог получить данные — чудо.Почему же чудо? Обычное раздолбайство.
В мелких компаниях такое часто случается, но если бы подобная история про Amazon или Google попала бы в прессу — то иск на много миллионов был бы неизбежен.
но если бы подобная история про Amazon или Google попала бы в прессу — то иск на много миллионов был бы неизбежен.
Что Вас заставляет так думать?
И вы вот это, например, вспомните.
А там даже не доступ какого-то левого менеджера к пользовательстким данным, а просто — сбор «сырах» данных, к которым особо-то и доступа ни у кого не было.
Так что то, что «экономист из одной большой компании» это провернул и не попался — это круто. А вот только рассказывать про нарушение трудовой дисциплины и, тем более, выдавать это за доблесть — не стоит.
А там даже не доступ какого-то левого менеджера к пользовательстким данным, а просто — сбор «сырах» данных, к которым особо-то и доступа ни у кого не было.
Так что то, что «экономист из одной большой компании» это провернул и не попался — это круто. А вот только рассказывать про нарушение трудовой дисциплины и, тем более, выдавать это за доблесть — не стоит.
Собрать лишние данные — это не тоже самое, что построить отчёт по уже имеющимся. Думаю оный экономист имел все права на данные к тому же.
Но направление мысли я понял, спасибо.
Но направление мысли я понял, спасибо.
Думаю оный экономист имел все права на данные к тому же.Я вот — ни разу не уверен. Более того, уверен на 99%, что он этих прав не имел.
То есть понятно, что ему нужны были агрегированные данные, по которым можно было бы построить какие-то тренды. Но судя по описанию — доступ-то он получил к «сырым» данным. То есть, например, мог узнать кто, когда и чего купил в этой фирме. А дальше мы налетаем прямиком на разнообразные законы о персональных данных и получаем повестку в суд.
После чего «ТЗ точное» и «неделя работы» вдруг оказываются вовсе не таким уж непостижимо ужасным требованием…
Экономистам, аналитикам, да хоть админам, а они должны часть "разработать SQL-запрос" задачи «отдать клиенту в экселе какие-то данные» делегировать разработчику.
Разработчику поставлена задача, которая не является задачей для разработчика.
Собирать требования не задача разработчика, писать ТЗ не задача разработчика, писать SQL-запросы не задача разработчика, тестировать не задача разработчика, сдавать систему не задача разработчика…
Через сколько итераций перебора задач мы поймем, что на IT-проекте в нет задач для разработчика?
Писать SQL-запросы — задача разработчика. Выгружать результаты их работы — нет. Если бизнесу нужен какой-то отчёт по РСУБД в каком-то неподдерживаемом сейчас системой формате, то задача разработчика написать запрос, выбирающий данные из базы, написать модуль выгрузки в этот формат, написать UI для этого отчёта. Не нужны модуль выгрузки и UI, бизнес довольствуется SQL-запросами (как у нас, например, аналитики) — задача разработчика написать запрос. Желательно протестировать, возможно на боевой базе с чутким мониторингом нагрузки — вдруг он операционную деятельность положит. Но вот как-то из консоли или IDE выгружать результат запроса в Excel — не его задача.
Окей. Если никакие UI, модули и т.д. не нужны, надо просто выгрузить данные за определенный период, например по продажам, в Excel (тем более это можно сделать через источники данных, куда этот запрос можно воткнуть и забыть), кто этим должен заниматься программист или менеджер?
Программист пишет SQL-запросы, передаёт их менеджеру, менеджер втыкает их в свой Excel. Если слабо разбирается в этом, то техподдержка/админы должны втыкать, тем более что права менеджеру может потребоваться давать, что программист точно делать не должен даже если у него есть рутовые.
Чисто в теории, программист, после разработки запросов, если у него есть права для выполнения этого запроса на боевой базе, если у него есть Excel, если он знает как результат запроса можно получить в Excel (я вот не знаю, последний раз с Excel работал в прошлом тысячелетии и то проверял как он открывает CSV файлы, которое выгружало моё приложение — тогда плохо открывал) может приложить результат запроса по текущим данным как образец результатов запросов, но это будет:
а) жестом доброй воли
б) риском получить «уточнение требований» типа «отрицательные значения выделить жирным красным, посчитать общие итоги и подитоги по месяцам, причём ячейка „месяц“ должна должен быть объединением для всех строк месяца, а не повторяться каждый раз, а подитог быть первой строкой»
в) риском постоянно получать подобные задачи, причём не только от данного конкретного менеджера, не смотря на обещания менеджера «первый и последний раз и никому не скажу»
г) уменьшением времени на исполнение своих прямых должностных обязанностей, что приведёт к увеличению календарных сроков окончания нормальных задач по разработке и, возможно, срыву дедлайнов. В лучшем случае — к неуменьшению технического долга, если открытых задач нет и обычно в свободное время что-то рефакторится. В самом лучшем случае — к замедлению профессионального роста: вместо того, чтобы новый фреймворк как инструмент решения прикладных задач пользователей софта изучать, программист будет Windows и Excel изучать как инструмент для решения своих прикладных задач
Чисто в теории, программист, после разработки запросов, если у него есть права для выполнения этого запроса на боевой базе, если у него есть Excel, если он знает как результат запроса можно получить в Excel (я вот не знаю, последний раз с Excel работал в прошлом тысячелетии и то проверял как он открывает CSV файлы, которое выгружало моё приложение — тогда плохо открывал) может приложить результат запроса по текущим данным как образец результатов запросов, но это будет:
а) жестом доброй воли
б) риском получить «уточнение требований» типа «отрицательные значения выделить жирным красным, посчитать общие итоги и подитоги по месяцам, причём ячейка „месяц“ должна должен быть объединением для всех строк месяца, а не повторяться каждый раз, а подитог быть первой строкой»
в) риском постоянно получать подобные задачи, причём не только от данного конкретного менеджера, не смотря на обещания менеджера «первый и последний раз и никому не скажу»
г) уменьшением времени на исполнение своих прямых должностных обязанностей, что приведёт к увеличению календарных сроков окончания нормальных задач по разработке и, возможно, срыву дедлайнов. В лучшем случае — к неуменьшению технического долга, если открытых задач нет и обычно в свободное время что-то рефакторится. В самом лучшем случае — к замедлению профессионального роста: вместо того, чтобы новый фреймворк как инструмент решения прикладных задач пользователей софта изучать, программист будет Windows и Excel изучать как инструмент для решения своих прикладных задач
Какой-то бесполезный разработчик получается.«Чучка не читаль, чукча писатель».
Еще возникает мифический человек, у которого есть права и возможность запускать запросы, но их не умеет писать. Может его научить, а разработчика уволить? Сознательно не произношу слово «деплой».
Какой-то вырожденный случай разделения труда, потерялось промежуточное звено без котороо задача не может быть выполнена.
Не понимаю, чего все привязались к Excel, Excel умеет и CSV открывать и запросы запускать к БД, нет большой проблемы, если данных меньше миллиона строк (или сколько там сейчас).
Еще возникает мифический человек, у которого есть права и возможность запускать запросы, но их не умеет писать. Может его научить, а разработчика уволить? Сознательно не произношу слово «деплой».
Какой-то вырожденный случай разделения труда, потерялось промежуточное звено без котороо задача не может быть выполнена.
Не понимаю, чего все привязались к Excel, Excel умеет и CSV открывать и запросы запускать к БД, нет большой проблемы, если данных меньше миллиона строк (или сколько там сейчас).
нет большой проблемы, если данных меньше миллиона строк (или сколько там сейчас).Проблема таки есть: выгрузка данных «в сыром виде» в Excel скорее всего — прямое нарушение закона, а для какой-то осмысленной их обработки требуется ТЗ и прочее.
Именно писатель, а не читатель.
У нас вот полотдела аналитики такие мифические, мы им пишем запросы, они их сами запускают, SQL немного знают, чтобы что-то поправить типа условий, но если пишут сами что-то с семиэтажными джойнами и подзапросами, то вполне могут базу положить.
Задача может быть выполнена:
1) аналитик формирует требования (допустим SQL не знает, как и всякие ODBC)
2) программист пишет запрос, возможно деплоит его в качестве view на сервер
3) техподдержка/админы обеспечивают аналитику возможность запустить запрос в привычной ему среде (Excel тот же), либо экспортировать в неё. Как вариант сами запускают запрос, экспортируют его в нужный формат и передаёт аналитику.
Просто в этой ситуации аналитик забыл про существование поддержки, тех, кто ему комп настраивает, ексель устанавливает. И поставил задачу программисту не проведя аналитическую работу.
Я не знаю, что умеет Excel. Мне его даже запустить негде, если вдруг фирма мне его купит — это ещё винду нужно покупать, для задач которые возникают реально раз в год. Ставят мне задачу выгрузки из софта в Excel данных — я буду искать библиотеку работы с Excel, чтобы сделать в софте модуль выгрузки. Ставят мне задачу выгрузки в CSV — сделаю модуль выгрузки в CSV, если стандартной библиотеки не хватит. Чисто в теории я могу сделать выгрузку результатов SQL-запроса в Excel, вместо разработки модуля выгрузки, но это не входит в мои обязанности как разработчика, и не входит в круг моих профессиональных знаний — мне нужно будет проводить исследование того, как обычно это делается. Возможно устанавливать какие-то дополнительные инструменты, возможно запрашивать приобретение лицензий на Windows и Microsoft Office, возможно запрашивать создание учётки на сервере с СУБД (MySQL, например, поддерживает нативно экспорт в CSV, но естественно файлы пишет на ФС сервера, на который штатно доступа у меня нет, только к СУБД как таковой), а возможно лишь Ctrl+A и Ctrl+C в IDE, которой я пользуюсь для отладки запросов, Alt+Tab на текстовый редактор, Ctrl+V и Ctrl+S и всё. Для меня по сути задачи «выгрузка в Excel», «выгрузка в 1С», «выгрузка в IBM Notes» равнозначны, разве что я откуда-то знаю, что Excel — это файлы формата xsl, о котором я знаю только то, что это формат электронных таблиц от Microsoft. Кажется бинарный и закрытый.
У нас вот полотдела аналитики такие мифические, мы им пишем запросы, они их сами запускают, SQL немного знают, чтобы что-то поправить типа условий, но если пишут сами что-то с семиэтажными джойнами и подзапросами, то вполне могут базу положить.
Задача может быть выполнена:
1) аналитик формирует требования (допустим SQL не знает, как и всякие ODBC)
2) программист пишет запрос, возможно деплоит его в качестве view на сервер
3) техподдержка/админы обеспечивают аналитику возможность запустить запрос в привычной ему среде (Excel тот же), либо экспортировать в неё. Как вариант сами запускают запрос, экспортируют его в нужный формат и передаёт аналитику.
Просто в этой ситуации аналитик забыл про существование поддержки, тех, кто ему комп настраивает, ексель устанавливает. И поставил задачу программисту не проведя аналитическую работу.
Я не знаю, что умеет Excel. Мне его даже запустить негде, если вдруг фирма мне его купит — это ещё винду нужно покупать, для задач которые возникают реально раз в год. Ставят мне задачу выгрузки из софта в Excel данных — я буду искать библиотеку работы с Excel, чтобы сделать в софте модуль выгрузки. Ставят мне задачу выгрузки в CSV — сделаю модуль выгрузки в CSV, если стандартной библиотеки не хватит. Чисто в теории я могу сделать выгрузку результатов SQL-запроса в Excel, вместо разработки модуля выгрузки, но это не входит в мои обязанности как разработчика, и не входит в круг моих профессиональных знаний — мне нужно будет проводить исследование того, как обычно это делается. Возможно устанавливать какие-то дополнительные инструменты, возможно запрашивать приобретение лицензий на Windows и Microsoft Office, возможно запрашивать создание учётки на сервере с СУБД (MySQL, например, поддерживает нативно экспорт в CSV, но естественно файлы пишет на ФС сервера, на который штатно доступа у меня нет, только к СУБД как таковой), а возможно лишь Ctrl+A и Ctrl+C в IDE, которой я пользуюсь для отладки запросов, Alt+Tab на текстовый редактор, Ctrl+V и Ctrl+S и всё. Для меня по сути задачи «выгрузка в Excel», «выгрузка в 1С», «выгрузка в IBM Notes» равнозначны, разве что я откуда-то знаю, что Excel — это файлы формата xsl, о котором я знаю только то, что это формат электронных таблиц от Microsoft. Кажется бинарный и закрытый.
Я с вами согласен при условии, что все участники процесса решили работать по самому махровому Waterfall какой есть. Привет ребятам из Agile-топиков.
Также в процессе произошла подмена понятий разработчик -> программист (в вашей интерпретации чуть ли не кодер).
В принципе ваша точка зрения понятна, вы четко обозначили свою роль и все риски переложили на других людей.
В целом выходит ситуация из анекдота «Сколько программистов нужно, чтобы вкрутить лампочку», когда, чтобы достать данные из БД в человеко-читаемый формат нужно минимум 4 человека.
Также в процессе произошла подмена понятий разработчик -> программист (в вашей интерпретации чуть ли не кодер).
В принципе ваша точка зрения понятна, вы четко обозначили свою роль и все риски переложили на других людей.
В целом выходит ситуация из анекдота «Сколько программистов нужно, чтобы вкрутить лампочку», когда, чтобы достать данные из БД в человеко-читаемый формат нужно минимум 4 человека.
Сейчас там вроде xlsx. Кажется небинарный и открытый.
Почитайте спеку на досуге. Он формально набор xml'ей в zip архиве, но реально довольно похож на старые OLE2'шные бинарные форматы. Или, если хотите нормально спать, не читайте.
И его открытость, к сожалению, только на бумаге. На деле часто выясняется, что реальные форматы word/excel отличаются от спеки.
Если говорить не о чтении, а о записи данных (формировании xlsx-файла с нуля), то реализации Apache POI (там их две, кстати) обычно хватает за глаза… Это что касается java, для других языков — не интересовался, подсказать не могу...
PS сорри за некропост :)
Там, что в HSSF, что в XSSF проблем выше крыши. Посмотрите в их багзиллу и dev@poi.a.o, если интересно.
Вообще, на простом экспорте (когда можно обойтись csv или его чуток не хватает), вы проблем, скорее всего, не встретите. А при использовании формул, разных хитрообъединенных ячеек и, например, условного форматирования нарваться на corner case проще простого. И это при том, что Apache POI, пожалуй, самая зрелая и полная из библиотек для работы с форматами MSO.
Ставят мне задачу выгрузки в CSV — сделаю модуль выгрузки в CSV, если стандартной библиотеки не хватит. Чисто в теории я могу сделать выгрузку результатов SQL-запроса в Excel, вместо разработки модуля выгрузки, но это не входит в мои обязанности как разработчика, и не входит в круг моих профессиональных знаний — мне нужно будет проводить исследование того, как обычно это делается.
Задачу вам ставят — написать sql запрос, результаты которого можно будет потом скинуть в эксель. Если у вас какой-то опыт работы вообще есть в отрасли, вы знаете, что результат запроса можно будет средствами клиента СУБД скинуть в csv, а csv эксель умеет читать. Об этом вы и расскажете менеджеру. Менеджер договорится с админом, чтобы он сделал из вашего запроса csv, а потом сделает из него нужный эксель. Конечно, если менеджер с опытом, он всё это уже знает и рассказывать ему ничего не придётся. Но запрос всё равно надо будет написать, да.
Если мне, как разработчику, ставят задачу написать SQL-запрос, то я беру его и пишу. Если мне, как разработчику, ставят задачу сделать выгрузку, то я пишу модуль выгрузки. Или даже отдельную утилиту. Если меня привлекают к решению бизнес-проблемы получения выборки как эксперта в области разработки, то я предложу или SQL-запрос написать, или модуль/утилиту, дам ТЭО разных вариантов и пускай бизнес решает.
Хм… и куда экономист должен воткнуть эти SQL-запросы?
Господа гусары, МОЛЧАТЬ!!!
М: Мне завтра надо. И вообще это — однократная работа. Выгрузи уж как нибудь вот эти и вот эти столбцы.
Вот такая однократная работа очень часто превращается в – «а помнишь ты мне выгрузку делал, надо повторить. Только …».
Уважаемый автор, а есть ли перевод сего великолепного произведения на английский язык? Хотелось бы поделиться.
“Направить в отдел стратегического планирования для подготовки ТЗ — Иегова”
Генеральному директору Иегове
от начальника отдела стратегического планирования Михаила
В целях снижения себестоимости системы предлагаю запитать оба светила от одного источника энергии, а кислород заменить азотом.
“Хотя бы 50% кислорода надо оставить, а то пользователь задохнется — нач. отд. тестирования и техподдержки Рафаил”
“Хватит и 25% — Иегова”
Генеральному директору Иегове
от начальника отдела системотехники Люцифера
В ходе работ по проекту Genesis (стадия “Да будет свет”) выявлены следующие трудности: у нас отсутствует компактный источник бесперебойного свечения с распределителем на два светила. Предлагаю воспользоваться стандартным источником типа “красный карлик”, а в качестве ночного светила применить зеркало.
Напомнило бессмертное — «Сотворение мира»
http://mif33.spybb.ru/viewtopic.php?id=302
Автор, спасибо тебе!
Шедеврально!
Эка как у вас наболело, однако)
Эка как у вас наболело, однако)
Sign up to leave a comment.
Пьеса «Технический долг»